Do network service qubes require a disposable vm?

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.

@1of7

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.

3 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:

  1. customized home directory and settings
  2. 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. :slight_smile:

@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.

Agreed. Thoughts @Marmarek @ADW ?

B

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. :confused:

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