Make sys-firewall and sys-usb 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.

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

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

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

[andrewdavidwong]

Relevant documentation:
https://www.qubes-os.org/doc/disposablevm-customization/#using-static-disposablevms-for-sys-

[SvenSemmler]

@3hhh you wrote "The new named DispVM is basically a non-volatile private.img anyway." ... can you explain. I am confused about this. What you describe would be an AppVM (non-volatile private.img). As named DispVM is "disposable"/stateless ... so private.img will not persist. Right?

[marmarek]

What you describe would be an AppVM (non-volatile private.img). As named DispVM is "disposable"/stateless ... so private.img will not persist. Right?

This is correct.
Changes in private.img of DVM template (which is in fact AppVM) do persist and are visible to DispVMs (named or not) based on this DVM template. But changes in DispVM itself are discarded.

[3hhh]

Exactly.

Fyi:
I'm still using named disposable VMs for all of sys-net, sys-firewall and sys-usb and have never noticed any major drawback. So I still think this should be the default.

The only inconvenience I noticed:
Configuring the network manager in sys-net to save Wifi networks across boot sessions (essentially the nm-applet becomes useless for that task). It looks like one needs to store an appropriate config file inside the template VM at /rw/config/NM-system-connections

@andrewdavidwong : Thanks for the doc!

[unman]

On Mon, Feb 25, 2019 at 02:26:58AM -0800, 3hhh wrote: Exactly. Fyi: I'm still using named disposable VMs for all of sys-net, sys-firewall and sys-usb and have never noticed any major drawback. So I still think this should be the default. The only inconvenience I noticed: Configuring the network manager in sys-net to save Wifi networks across boot sessions (essentially the nm-applet becomes useless for that task). It looks like one needs to store an appropriate config file inside the template VM at `/rw/config/NM-system-connections`

This is *exactly* the reason why this should not be the default. Let's not raise barriers to widespread adoption. The option should be better publicised but until there is some method for using the applet (or a replacement), not the default.

[3hhh]

Well, there's still some work to do for making it the default, I agree. It's not that much though as I see it (1 issue concerning 1/3 VMs so far?).

I'd suggest listing other potential inconveniences/anti-features here so that they can be tracked & hopefully resolved mid to long term.

[imjustmatthew]

It seems like the Network Manager applet the biggest impediment to making this the default for sys-net. sys-usb seems to have no blocking issues. sys-firewall might or might not have more complex issues, but certainly has a documentation hurdle.

Would it be reasonable to split this into 3 issues (sys-usb, sys-firewall, and sys-net) so that they can each be handled separately? It feels like sys-usb is where the greatest risk of persistent threats exists since we're exposing it to a lot of dongles and such and it's also the simplest to fix. Tangible progress can be made there while the issues of sys-net and sys-firewall are worked over time.

[andrewdavidwong]

It seems like the Network Manager applet the biggest impediment to making this the default for sys-net. sys-usb seems to have no blocking issues. sys-firewall might or might not have more complex issues, but certainly has a documentation hurdle.

Would it be reasonable to split this into 3 issues (sys-usb, sys-firewall, and sys-net) so that they can each be handled separately? It feels like sys-usb is where the greatest risk of persistent threats exists since we're exposing it to a lot of dongles and such and it's also the simplest to fix. Tangible progress can be made there while the issues of sys-net and sys-firewall are worked over time.

It may make sense to do this at some point. However, to quote Marek in #3704 (comment) above:

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.

So, I wouldn't infer that sys-usb has no blockers and could easily be handled right now.

[marmarek]

Actually, maybe those all issues are simply documentation issues? Like, include first step of custom firewall to make sys-firewall non-disposable? This would be easier to address with version-specific documentation ( #5308 )

[3hhh]

I agree that documentation would help for now.

Mid- to long term the ability to persist a few files rather than the entire private.img would overcome the issues mentioned by @marmarek. Some progress was made with that (aka "bind dirs" [1]), but is not available for disposable VMs afaik. ATX - or whatever that closed source alternative to Qubes OS is called - is using persistence that way for a while now: They appear to simply whitelist the files that may persist [2].

I however have never encountered the need to persist anything in sys-usb, i.e. I don't see many blockers there neither.
Of course it would require a version change and a rather clear announcement somewhere so that users don't move something to the home directory and then lose their data ("But it did work before!").

[1] https://www.qubes-os.org/doc/bind-dirs/
[2] https://www.platformsecuritysummit.com/2018/speaker/pratt/

[andrewdavidwong]

Actually, maybe those all issues are simply documentation issues? Like, include first step of custom firewall to make sys-firewall non-disposable? This would be easier to address with version-specific documentation ( #5308 )

This issue is about having them disposable by default so that the user doesn't have to read the documentation and do it themselves. So, documentation by itself would not be sufficient to satisfy this particular request. (Of course, it's your prerogative to decide that this particular issue is a won't do and that we'll just provide documentation instead.)

[marmarek]

I think I wasn't clear. "those all issues" is about issues caused by DisposableVM as sys-* by default. Things like adding extra steps how to add custom firewall rules. Not how to make sys-* DisposableVM (we already have this documentation).

[andrewdavidwong]

I think I wasn't clear. "those all issues" is about issues caused by DisposableVM as sys-* by default. Things like adding extra steps how to add custom firewall rules. Not how to make sys-* DisposableVM (we already have this documentation).

If I understand correctly:

(1) We make ServiceVMs disposable by default.
(2) This causes problems for certain advanced use cases.

Nonetheless, we do not regard (2) as a reason to block (1). Instead, we proceed with (1) and have documentation that explains how to work around (2).

I think this would be reasonable.

[3hhh]

If I understand correctly:

(1) We make ServiceVMs disposable by default.
(2) This causes problems for certain advanced use cases.

Nonetheless, we do not regard (2) as a reason to block (1). Instead, we proceed with (1) and have documentation that explains how to work around (2).

That's another option which is available right now and would work for all service VMs except sys-net (unless one wants to break Wifi settings being stored).

[92VV3M42d3v8]

There may be an option added to installation screens to create disposable sys-* but users might be allowed to continue with non-disposables if they want?
Edit: Btw I am using disp sys-net, sys-firewall and sys-usb without much problem for long time.

[andrewdavidwong]

Updated title to match (what I gather to be) what was actually implemented.

[IOZZYS]

I would love to have the option to set bind dirs in a disposable template which get applied to the dvm that bases itself upon that disposable template.
This way I would have a fully immutable dvm, with the exception of the files/directories listed in the 50_user.conf file in the disposable template of the dvm, without having to fear that malware entering the dvm could try to make it's self persistent by adding/editing a 50_user.conf file inside the dvm.
Because 50_user.conf would be not persistent inside the dvm, only inside the disposable template that it is based on.

[marmarek]

This way I would have a fully immutable dvm, with the exception of the files/directories listed in the 50_user.conf file in the disposable template of the dvm

No, it doesn't work this way. In disposable qube really nothing persist, be it listed with bind dirs or else.