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.

[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 notifications@github.com 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: https://github.com/QubesOS/qubes-issues/issues/1006#issuecomment-442617000

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