Minimal state app qubes

[v6ak]

Minimal state AppVM would be a VM, that holds some state in some explicitly listed directories, but is does not allow malware to simply persist after reboot (unless misconfigured).

Example of usage: NetVM

Current state: When the NetVM is compromised, some malware can persist in init scripts or maybe even in .bashrc/.zshrc. This simplifies multi-stage attacks, where attacker installs some backdoor in NetVM and waits until some other useful vulnerability (e.g. XEN privilege escalation) is found. Then, some other stage of attack is initiated then.

Solution: The NetVM would just store network settings, but not anything else. It would be much harder to store a persistent malware that survives reboot, so such multi-stage attack is much less likely to be successful.

Implementation with current Qubes

Even with Qubes 3.0-RC1, one can probably make such minimal-state VM, but with some disadvantages:

• Clone a TemplateVM
• Add nosuid (and possibly also noexec) attribute to /rw in /etc/fstab
• Change the symlinks to /rw – there should be as few such symlinks as possible.

There are obviously two disadvantages. First, such process is error-prone, but hopefully manageable. Second, any MSVM needs its own AppVM, which requires more space and makes administration harder. Such cloned AppVM might differ only in several symlinks and fstab options for /rw.

proposed implementation:

See #1006 (comment)

[marmarek]

We have some idea similar to this one, but going even further. I think Joanna will write some blog post about this in details, but basically its about creating one-service VMs with very small memory footprint. Such VM will run (almost) only qrexec-agent, which will handle service calls. There may be no Xorg (with all GUI processes) for example. I think it all can be packaged in initramfs, which will make it really fast to start - maybe even so fast that it can be started on demand when the service needs to be called (and only for that).
The perfect use case would be gpg backend domain, but maybe also firewallvm.
But first some other features needs to be implemented, for example #889, and maybe #830.

Anyway, the better place for discussions on new features is mailing list. Here only add link to the discussion, and later paste final design.

[v6ak]

I'd like to attach it to a current discussion, but I can't find a relevant one. Is there any? should I create a new one?

This sounds cool, but I am not sure if they can be easily applied to sys-net.

Removing all the GUI from sys-net would require moving NetworkManager applet (i.e. nm-applet) functionality somewhere else. If we want to support everything that nm-applet supports (e.g. various WiFi options, WPA2 enterprise, certificates, VPNs, USB modems, …), this is a non-trivial task.

Moreover, running Wireshark would be likely harder. Now, I can just start Wireshark from sys-net if memory limits allow it. (I've reduced memory to 300MiB for sys-net, so running Wireshark is sometimes not very great.)

I can, however, imagine such ServiceVMs for FirewallVM and GPGVM and possibly some others. I've tried it in sys-firewall, but it kills the qrexec daemon, as it seems to depend on X11. But I hope it can be easily fixed.

[marmarek]

I'd like to attach it to a current discussion, but I can't find a relevant one. Is there any? should I create a new one?

I think there is currently none on this subject.

Removing all the GUI from sys-net would require moving NetworkManager applet (i.e. nm-applet) functionality somewhere else. If we want to support everything that nm-applet supports (e.g. various WiFi options, WPA2 enterprise, certificates, VPNs, USB modems, …), this is a non-trivial task.

Yes, this approach for NetVM (or any VM which uses some GUI) can be tricky, but it is better to assume that NetVM can always be compromised anyway (same as your local wifi for example). #806 is about how further protect against attacks from netvm.

[esote]

@v6ak The original suggestion you give is very similar to using disposable sys-{net,firewall,usb} in R4 (see #3704). As far as minimal goes, this could be done with the minimal Fedora template (although not as minimal as @marmarek describes with only qrexec-agent).

[v6ak]

DVMs in Q4 is a partial solution for this, but I agree that it is quite similar. Note that the adjective „minimal“ was related to state (i.e., it can save just few files/directories/whatever, not whole traditional /rw with rc.local, bind-dirs, /home/user/* (especially .bashrc and similar) and so on…). It was not related to minimal templates. Having minimal templates is orthogonal to storing minimal state.

…

On November 28, 2018 10:47:14 PM GMT+01:00, Esote ***@***.***> wrote: @v6ak The original suggestion you give is very similar to using disposable sys-{net,firewall,usb} in R4 (see #3704). As far as minimal goes, this could be done with the minimal Fedora template (although not as minimal as @marmarek describes with only qrexec-agent). -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1006 (comment)

-- Sent from my fruity BlackBerry phone. Please excuse my brevity.

[deeplow]

I started a thread on qubes-devel to propose the idea of having minimal state app qubes where extra state is explicitly declared in a vm-config-like qube feature.

Discussion conclusions

1. configuration in /rw/config/qubes-bind-dirs.d to be ignored (but template-provided bind-dirs are still respected)
2. Bind dirs to be explicitly listed under a vm-config-like qubes feature prefix (suggestions: bind-dirs.*, persistent-dir.*)
3. On app qube startuo bind-dirs configuration to be read instead from qubesdb using the chosen prefix
4. When creating a qube: have implicit default include /home, but if one starts configuring it manually, /home would need to be explicitly included (if desirable). Ofc, the (G)UI could propose this option to make it easier.

Additional implementation notes:

• there is "os" feature that can be used to distinguish OSes (that have qubes tools installed), and also we have
  proper mechanism for feature discovery - "supported-feature" namespace - for a template to announce support for this configurable bind-dirs. That's important, because it isn't enough to say "Qubes 4.3 supports this" - you may have template imported from 4.2 for example, or some custom build or whatever. We can use a similar mechanism to give some hits for the GUI about configuring this thing if needed (which I doubt will happen anytime soon - I don't see a practical chance for non-Linux support of this feature happening).

• One thing to consider is length limitation of qubesdb keys - 63 chars. Values can be much longer (3k). So, the longer the prefix, the shorter actual key. But it isn't necessarily a problem, the actual path can be put as a value, and key could be something short like "123-my-first-path" (in most cases ordering doesn't matter, but in the few cases where it does, better to have this numbered prefix).

• (added Dec 2024) For this to be even more useful, bind-dirs would also need to be able to persist individual files (as opposed to only directories). Example use-cases: persist only certain browser configuration files.

[deeplow]

@andrewdavidwong candidate for privacy label.

Some users may wish to preserve only minimal configurations (e.g. persist browser Downloads but nothing else). Currently they either save everything or nothing.

Another privacy angle to this is that where a disposble qube is not fitting (i.e. the user needs to save some data), it can be much harder for an attacker to create persistence (e.g. a RAT) if only certain application configuration files are persistent. Something which by default is trivial to do (as soon an attacker gets remote code execution, all they have to do is to modify /rw/config/rc.local).

[marmarek]

Bind dirs to be explicitly listed under a vm-config-like qubes feature prefix (suggestions: bind-dirs.*, persistent-dir.*)

I like persistent-dir prefix. Or, since it can be also applies to single files, maybe just persist/? Then the key name would be arbitrary string (recommend starting with user prefix?) and the key value would be the path to persist. This is to avoid running into qubesdb key length issue. For example:

/persist/network-manager = "/etc/NetworkManager"
/persist/machine-id = "/etc/machine-id"
/persist/firefox = "/home/user/.mozilla/firefox"

or with some user prefix like user.firefox?

I'd say this whole feature should be enabled with qvm-service, lets name it custom-persist. When enabled, the following would happen:

1. No config in /rw would be read (rc.local, qubes-user-firewall-script, bind-dirs etc). Configs in other locations are handled normally (especially - bind-dirs configs in /etc are handled)
2. /home and /user/local would not be mounted unless explicitly listed
3. Default home would be populated based on /etc/skel (unless /home/ in the root filesystem already contains user dir)
4. Bind-dirs read the qubesdb /persist entries in addition to the config files.
5. Entries in qubesdb /persist for /home and /usr/local are handled specially - are mapped to /rw/home and /rw/usrlocal respectively (instead of /rw/bind-dirs/home and /rw/bind-dirs/usr/local).

[deeplow]

Bind dirs to be explicitly listed under a vm-config-like qubes feature prefix (suggestions: bind-dirs., persistent-dir.)

I like persistent-dir prefix. Or, since it can be also applies to single files, maybe just persist/? Then the key name would be arbitrary string (recommend starting with user prefix?) and the key value would be the path to persist.

persist sounds good to me. And I generally agree with the remaining implementation items.

3. Default home would be populated based on /etc/skel (unless /home/ in the template already contains user dir)

I had not thought about this in the original proposal, but the possibility of having /home/ come from the template on every boot solves yet another issue users have:

• having multiple app qubes with basically the same application settings with very minute differences (e.g. different firefox extension data, but the same core settings)
• but still with a way to edit the common configuration without needing to edit it on every single app qube

Currently this is not possible because /etc/skel is only copied only on the first app qube boot.

Commenting specifically about the template's /home being made available (as opposed to the regular /etc/skel) I think it could good in practice good but also catch some user off-guard. The good aspect is that the user would simply be able to configure the program directly in the template (although generally discouraged) and then that configuration would be available for all app qubes with custom-persist. The downside is that some users may be caught off-guard by this, since it goes against the general expectations that an app qube has its own clean /home/. For example, some users may copy files to the template (e.g. a .deb to install a program) and then they would have a ~/QubesIncoming/something.deb in the app qube which "always returns" after they delete it and restart the qube.

[marmarek]

This proposal doesn't change how template's /home works - it's still private to the template. I meant /home dir in the root filesystem - which normally isn't easy to access (it's covered by bind-mount from /rw/home). I clarified my description above.

Yes, I think it's discouraged to configure apps this way in the template itself. But one can launch a (disposable) qube, configure apps there, and qvm-copy relevant files back to the template, to be placed in /etc/skel (or /home in the rootfs, if one knows the right incantation, which is mount --bind / /mnt and then access /mnt/home). I guess this aspect can get simplified with some tool that will handle starting disposable qube and copying files back (after confirming its list with the user). But that's offtopic in this issue.

[DemiMarie]

Is NetworkManager secure against malicious network settings?

For the specific case of sys-net, I wonder if this would be better handled by providing an RPC interface for sys-net to store its settings somewhere and later retrieve them.

[marmarek]

Is NetworkManager secure against malicious network settings?

That's irrelevant for this issue, which is about generic mechanism, not a specific implementation for NetworkManager.

[DemiMarie]

Linux filesystems are generally not secure against malicious disk images. Is it fair to state that this does not make this issue irrelevant?