Consider making sys-VMs disposable by default

[3hhh]

Qubes OS version:

4.0

Description

I tested disposable sys-usb, sys-net and sys-firewall for quite a while now in 4.0 and it seems to be working well.

This is just a reminder to consider making that the default.

At least the last time I did a 4.0 install it wasn't the default.

[marmarek]

This is not that easy in general case. In sys-net, you want to keep wifi settings persistent. In sys-firewall you may want to keep custom firewall scripts (https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). I don't have such example for sys-usb right now, but I'm sure such cases exists too.
Also, it is too late to change such things for 4.0.

Above points should be addressed first - some with documentation, some with some code.
Also, for 4.0 we need documentation how to switch system VMs to disposable ones.

[marmarek]

This is not that easy in general case. In sys-net, you want to keep wifi settings persistent. In sys-firewall you may want to keep custom firewall scripts (https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes). I don't have such example for sys-usb right now, but I'm sure such cases exists too.
Also, it is too late to change such things for 4.0.

Above points should be addressed first - some with documentation, some with some code.
Also, for 4.0 we need documentation how to switch system VMs to disposable ones.

[tasket]

@3hhh This idea has been tossed around for a long time. Seems related to issue #2748, which is an available service that protects the startup state of template-based VMs.

[tasket]

@3hhh This idea has been tossed around for a long time. Seems related to issue #2748, which is an available service that protects the startup state of template-based VMs.

[tasket]

One way to implement this is to support snapshots in the GUI and then allow the user to set one of the snapshots as a "boot point" for the VM. Whenever a boot point is set, on VM start Qubes would simply delete the current private volume and replace it with a copy of the indicated snapshot.

This is not complicated to implement and gives the user a simple way to control configuration of a VM -- such as adding Wifi access points or VPN config -- before "freezing" the VM at the current state with a boot point.

[tasket]

One way to implement this is to support snapshots in the GUI and then allow the user to set one of the snapshots as a "boot point" for the VM. Whenever a boot point is set, on VM start Qubes would simply delete the current private volume and replace it with a copy of the indicated snapshot.

This is not complicated to implement and gives the user a simple way to control configuration of a VM -- such as adding Wifi access points or VPN config -- before "freezing" the VM at the current state with a boot point.

[3hhh]

One way to implement this is to support snapshots in the GUI and then allow the user to set one of the snapshots as a "boot point" for the VM. Whenever a boot point is set, on VM start Qubes would simply delete the current private volume and replace it with a copy of the indicated snapshot.

Essentially that's template VMs for the private.img as well.

The existing template VM features cover most of the needs for e.g. sys-net already though as the relevant configuration tends to go to /etc/ or user programs tend to have a fallback to use configuration in /etc/ if none in /home/ is provided. Of course that is not perfect if an attacker can control the configuration in /home/...

So yes, your suggestion is superior, but not absolutely required.

I.e. users would have to modify the template VM(s) for customizations at the moment. I at least currently run it that way.

EDIT: Sorry, looks like I was confused... The new named DispVM is basically a non-volatile private.img anyway. So that can be configured in the respective template incl. /home/.

[3hhh]

One way to implement this is to support snapshots in the GUI and then allow the user to set one of the snapshots as a "boot point" for the VM. Whenever a boot point is set, on VM start Qubes would simply delete the current private volume and replace it with a copy of the indicated snapshot.

Essentially that's template VMs for the private.img as well.

The existing template VM features cover most of the needs for e.g. sys-net already though as the relevant configuration tends to go to /etc/ or user programs tend to have a fallback to use configuration in /etc/ if none in /home/ is provided. Of course that is not perfect if an attacker can control the configuration in /home/...

So yes, your suggestion is superior, but not absolutely required.

I.e. users would have to modify the template VM(s) for customizations at the moment. I at least currently run it that way.

EDIT: Sorry, looks like I was confused... The new named DispVM is basically a non-volatile private.img anyway. So that can be configured in the respective template incl. /home/.

[andrewdavidwong]

This seems related to #3258. In particular:

Essentially that's template VMs for the private.img as well.

It's not clear to me how this is different from what's requested in #3258.

[andrewdavidwong]

This seems related to #3258. In particular:

Essentially that's template VMs for the private.img as well.

It's not clear to me how this is different from what's requested in #3258.

[3hhh]

This seems related to #3258. In particular:

Essentially that's template VMs for the private.img as well.

I was rephrasing / trying to understand @tasket there; it's not related to the original request. In fact I think we went a little bit off topic.

It's not clear to me how this is different from what's requested in #3258.

Let me try to make it crystal clear:

This one is a request to change the Qubes installer to make the new named DispVM feature of 4.0 the default for the system VMs in Qubes 4+. As an alternative it would be nice if a user could make the decision during the installation (checkbox or so).

Apparently Marek doesn't consider the feature ready for that as of now though. The feature itself is implemented in 4.0 (not in 3.2) and can be used by advanced users already.

@tasket probably didn't know about that new feature yet.

#3258 is apparently requesting more granular persistence options for various mount points. It's partially implemented in 4.0 by the named dispVM feature (private.img either 100% persistent or not). Probably the request was written with 3.2 in mind.
Being able to choose which mount point is persistent or not is not required for an installer change from my point of view. It would just be an additional nice-to-have feature for power users. There's not even much of an advantage from a security perspective to have the ability to go "80% non-persistent" - malware may still go to the 20%.

For reference:
When I'm talking about named dispVMs I always mean
qvm-create --class DispVM -t [template] --label [label] [disp VM name]
in contrast to generic dispVMs with names such as disp123.

[3hhh]

This seems related to #3258. In particular:

Essentially that's template VMs for the private.img as well.

I was rephrasing / trying to understand @tasket there; it's not related to the original request. In fact I think we went a little bit off topic.

It's not clear to me how this is different from what's requested in #3258.

Let me try to make it crystal clear:

This one is a request to change the Qubes installer to make the new named DispVM feature of 4.0 the default for the system VMs in Qubes 4+. As an alternative it would be nice if a user could make the decision during the installation (checkbox or so).

Apparently Marek doesn't consider the feature ready for that as of now though. The feature itself is implemented in 4.0 (not in 3.2) and can be used by advanced users already.

@tasket probably didn't know about that new feature yet.

#3258 is apparently requesting more granular persistence options for various mount points. It's partially implemented in 4.0 by the named dispVM feature (private.img either 100% persistent or not). Probably the request was written with 3.2 in mind.
Being able to choose which mount point is persistent or not is not required for an installer change from my point of view. It would just be an additional nice-to-have feature for power users. There's not even much of an advantage from a security perspective to have the ability to go "80% non-persistent" - malware may still go to the 20%.

For reference:
When I'm talking about named dispVMs I always mean
qvm-create --class DispVM -t [template] --label [label] [disp VM name]
in contrast to generic dispVMs with names such as disp123.