Under what circumstances would service qubes such as: sys-whonix, sys-firewall, sys-net need to have a disposable vm (ex. as assigned in Qubes Manager)?
The question can be expanded to templates too, since they donāt have network access.
That are no circumstances that ārequireā disposable VMs for networking. You can use standalones, standard VMs with persistent home directories or fully volatile disposables to handle network services.
You might choose disposables for added security. sys-net is the āfront lineā in your network and gets exposed directly to everything that enters your machine. A disposable gives you a ācleanā VM every boot, mitigating potentially compromised files. sys-firewall can similarly benefit.
The only exception is sys-whonix. While it can function as a disposable (with the usual security benefits of a disposable), it becomes more vulnerable to de-anonymizing attacks and loss of privacy without persistence in subsequent reboots. So itās generally advised to use standard templates with persistent home directories. If you are concerned about the potential compromise of sys-whonix, just occasionally replace it with a clean VM.
1 Like
Not sure how you are expanding that question to templates. Do you mean the use of disposable templates to create named disposables vs standard disposables? Creating a VM based on a disposable VM template (which itself is based on a primary template) has the benefit of producing a disposable with a constant name - which can make it easier to configure various settings that persist between boots (setting NetVMs, tray settings, audio, etc)
1 Like
The column with the heading āDefault DispVMā within the Qubes Manager has an entry āfedora-34-dvmā for sys-net and sys-firewall. It doesnāt seem appropriate to have a default dispvm for services.
The same for templates. Do you have default dispvms for templates. If so, how are they useful if templates cannot access a network?
The inference is that the disposable vm is a qube that instantiates a copy of the template. But isnāt this done with disposable vms using a disposable template?
Trying to develop a line of sight w.r.t. the intended purpose of the service and template default disposable vms.
Itās a bit slippery to understand at first. I will explain it in detail for clarity but itās not complicated.
Standard templates (ex. debian-10) define the root directory for any VM based on that template.
If you create a standard VM from a template, the root directory is always defined by the template while changes to the home directory persist between boots. For example, you can launch the VM, create āhello.txtā in ~/Documents, restart the VM and āhello.txtā will still be there. But any changes made to the root directory will be replaced with the template root directory.
If you create a disposable VM from a standard template, every time it launches, it will have a clean home directory and a root directory based on the template. Changes to the home directory in the disposable VM will not persist. Itās like a house that always cleans itself when you leave. You make a mess and leave. When you come back, itās perfectly clean. If you moved a chair, itās moved back to itās default position. But what if you want to rearrange some furniture? How do you customize your home arrangement?
In order to customize the home directory of a disposable (example: configure browser settings), you can base the disposable on a āsecondaryā template called a "disposable VM templateā. In this case, you create a disposable VM based on a standard template and then in dom0, define that VM as a ādisposable VM templateā. Then you can create disposable VMs based on the disposable VM template (rather than the standard template). Itās true, a ādisposable VM templateā is not a template in the strict sense of the word. It is only used to configure the home folder of disposable VMs.
To clarifyā¦ the structure of the final disposable VM is as such: the main template (that created the diposable VM template) defines the root directory and the disposable VM template defines the home directory. The disposable VM is āfully volatileā so any changes made during a session are lost and replaced by the main template and disposable VM template on the next reboot.
4 Likes
Disposable VMs based on a disposable VM template can be used for network services or web browsing or whatever you want. You just need to configure the appropriate settings. The primary benefits of using a disposable VM template instead of a standard template are:
- customized home directory and settings
- a constant name for the disposable which makes inter-VM settings easier to manage. i.e. if a disposable sys-net is based on a standard template, it will boot as "disp-#### each time, which makes it difficult to set the sys-firewall netvm setting. If you base sys-net on a disposable VM template, it will be disposable but will always be called sys-net, so you can easily set sys-firewall to āsys-netā.
1 Like
Ah, I see your real question now:
This value is inherited from the template from which the AppVM was generated.
For the standard use cases and operation of sys-net, I can see no reason why the sys-net VM should ever launch a disposable VM to handle a questionable file.
Feel free to set that value to (none).
Brendan
2 Likes
Thanks for the description of disposable vms (dvm) and disposable vm templates (dvmt). But the question was more to the assignment of a default dvm or dvmt to services and templates.
1 Like
I can see that now. Not sure why I found your question confusing. After @brendanhoar posted, I re-read your posts and they were perfectly clear. 
@brendanhoar Thanks, this is more to the point of the question. But with the hope of not to protracting this too much more, templates donāt appear to need assigned dvms either. Is there a policy somewhere on what should and should not have default dms, at least from a security perspective?
For example, opening a template then opening a file using a network enabled dvm would seem to defeat the intended isolation of the template.
So, as I said, I initially thought the reason templates have a default dvm is purely for inheritance to AppVMs and StandaloneVMs created from the template.
However after some experimentation, it appears that is not the case and that unless specified new VMs always end up with ādefaultā which is a pointer to use the global default value, which is user-managed.
So, no, I do not know why a template should have one, other than itās likely a setting that is available on all VMs regardless of type (template/appvm/standalonevm) or usage (user VM/sys VM).
Iām less worried about templates, which I believe are less likely to be sources of information leakage, than sys-* VMs, as I discuss below:
I just noticed that my sys-whonix was not set explicitly to (none) but to default which (luckily?) on my system happens to be set globally to (none). I wonder if this is a security concern, e.g. if my global dvm was set to something with direct internet access, but sys-whonix itself was behind a VPN. Some security guarantees might be broken if VPN-protected/TOR-protected qubes have a dvm that is not VPN-protected/TOR-protected.
B
Should a policy in the documents be setup describing the rational as to when a dvm shouldnāt be assigned to a qube? This may offer guidance to new Qubes users. My vote would be a fail conservative default dvm setting of ānoneā for templates and service qubes and let the user decide how much risk they are willing to take before changing to their preference.
I think the actual root question underlying this thread is something like:
āWhat is the Default DisposableVM Template setting?ā
The simplest answer I can think of is:
Whenever you open a disposable inside of a qube (e.g., right-click on a file ā View in DisposableVM), in order for that disposable to be created, it must be based on some disposable template. In other words, the system needs to know which disposable template to use in order to create the disposable you just requested. It uses the value of the setting Default DisposableVM Template. If you set this value to none, then it wonāt be able to create the disposable you requested. (There may be other uses of this setting, but this is the main use case that comes to mind for me.)
It seems that way to you two because youāve never had occasion to launch a disposable from a service qube. That is fine. Maybe other people do. I donāt know. For you, itās probably fine to set Default DisposableVM Template to none for those qubes, because you know youāll never need it.
Again, it seems this way to you two because youāve never had occasion to launch a disposable from a template. That is fine. Maybe other people do. I donāt know. For you, itās probably fine to set Default DisposableVM Template to none for those qubes, because you know youāll never need it.
Unless, of course, thereās some further or future use of that setting that makes it necessary. Personally, I just set it to an offline disposable template just in case.
This has come up several times before and is a separate matter from the root question of this thread. This is why there is now a warning when certain unsafe configurations are detected. Hereās an example issue where that warning is discussed:
I canāt find the earlier issue for which this feature was warning feature was implemented.
I would prefer that Qubes OS just have sensible, secure defaults in this regard (which it may already have, for all I know). Beyond that, Iām in favor of putting as much as possible in the software rather than the documentation. In general, āhereās why you should/shouldnāt/might want this or that settingā is something where either the logic should be built into the system to alleviate the user or, if thatās not realistic, be surfaced to the user through good UX within the context of that setting selection event. Iād like to see us move away from putting all sorts of things in the documentation that users ought to know and relying on that as a crutch when we know full well that the vast majority of users will never read it.
How about making the default disposableVM to not have any networking, to avoid unintentional leaks?
At first I didnāt understand the question. Then I thought I understood. But maybe I still donāt. 
When a disposable VM is spawned from a disposable VM template via the application menu or from within another VM or via dom0 with ex. qvm-run dispvm=disp-vm-dvm, the launched VM has a random name (ex. disp2434) and a completely volatile file system. It takes on the network setting of its parent disposable VM template. Why is it a problem for that disposable VM to access a network? Nothing on the network touches the disposable VM template or the appVM that triggered the launch.
Obviously if the disposable VM template is launched from Qubes Manager or via dom0 with ex. qvm-run disp-vm-dvm, the actual template will launch, but thatās not going to happen with right click āopen in disposableā from within an appVM or selecting it from the app menu.
So itās not clear to me why it poses such a risk. The original appVM that launches it remains compartmentalized and the disposable VM template that defines it remains halted.
AFAIK the problem might occur when you open a file in a disposableVM for editing. If you do it from inside an offline VM (e.g., TemplateVM), but the disposableVM has networking (which is the default!), then a malicious file could exploit something, go to the Internet and perform some kind of attack on the parent offlineVM.
1 Like