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
2 Likes
This is not exactly what I’m suggesting. I know that a DisposableVM based on a non-networked DVM Template will not have networking.
I suggest that the system should have a separate, preconfigured, non-networked DVM Template by default, which is used for “default DisposableVM Template” in various other AppVMs/TemplateVMs. Otherwise, as I mentioned above, an offline AppVM (or TemplateVM!) could in principle access the Internet.
I think my concern is that there’s a low-cost deanonymization attack vector in VMs that are upstream of a VPN or TOR connection that will bypass that VPN or TOR connection. Information disclosure and/or “persona disclosure” could break compartmentalization.
Avoiding the discussion on the default settings being secure and preventing the user from (unintentionally?) undermining them by changing them…how about…
Perhaps there should be new a Qubes RPC policy that monitors when the invoking VM and the disposable VM either have different network VMs assigned (including the case where the invoking VM has none but the disposable has network). The default policy would then be ASK (giving the reason of potential unintentional informational/persona disclosure)?
If this is already done/in the works, apologies.