Minimal state AppVMs

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

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

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

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