Over the years I saw similar projects come from Google like novm, unfortunately they never graduated beyond proof-of-concept stage.
Conversation
github.com/google/gvisor is more than a proof of concept, and the KVM platform implementation is close to what I want. It provides a way to have a "Linux" virtual machine without a Linux kernel. It runs on top of Linux on the host though, so it'd need to be ported elsewhere.
2
1
If we want the services provided by Linux, we have to run it somewhere either as host or guest. I have no basic issues with the Qubes+Xen virtual model; its robust in practice and clear-headed in concept. Feature-rich kernels are good to have if they run as guests.
1
A guest being compromised is still a problem even when it's isolated from the rest of the system. The security of the guests still matters and the Linux kernel is large part of their attack surface and is the weak link for sandboxes they have internally like the Chromium sandbox.
2
But then we're talking about sandboxes within sandboxes. Qubes focuses the user's attention on the qube/vm as the tool to manage risk. And I say this as author of a project that aims to improve Qubes guest security:
2
That's where my philosophy departs from Qubes': Allow the native security of the guest to do its job so malware won't have free (even if contained) reign, and remove anything that can compromise the startup environment.
1
Qubes' answer to the issue thus far has been "Use disposable VMs". But there are many use cases where they're difficult or impossible to use.
1
That doesn't resolve the issue of an application being compromised and an attacker gaining access to everything in that environment. Security against remote compromise and fine-grained containment certainly matters despite coarse-grained isolation chosen by the user higher up.
2
For the secure messaging example, it can be isolated per contact, and handling things like audio / video decoding for video calls can be isolated, as can cryptography, etc. Finer grained isolation than a group of applications for a certain identity / task is very important.
1
I think this approach is really less about containment and more about reducing the complexity of data formats exchanged between subsystems. Even the strong isolation of Qubes relies on the idea of simplified formats used at critical points.
1
It's fine-grained isolation of different components. Improving that involves having minimal attack surface exposed between the components, simple data formats and a focus on hardening the code most exposed at the boundaries with safe tools, etc.
Isolating per-contact in a messaging client, per-site in a browser, etc. is applying the same principle of QubesOS at a fine-grained level using existing privacy/security boundaries. Since they're existing boundaries, it doesn't require the user to do anything or be aware of it.
2
Isolating a specific component in an application is similar to QubesOS isolating the network stack. It's the same set of principles, and I don't see how the coarser grained QubesOS isolation replaces doing this. They aren't competing technologies but rather complementary ones.