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.
Conversation
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
IDK if computer science has a usable model for fine-grained containment, especially since this leads to internally-managed boundaries that the user cannot see. In that case, even experts have trouble discerning what is what.
1
UI complexity has to be increased by some minimal amount to improve security, which Qubes handles rather well. Its true for anything, like messaging clients that require a verification "ritual", etc. OTOH, simplification sometimes compromises security (browsers offer examples).
1
No, it doesn't. There are plenty of security features not requiring any increase in complexity of the UI. There are many existing security boundaries that can be reinforced with no added complexity and doing that is quite valuable. It has huge benefits for large numbers of users.
Some security improvements require increasing complexity for users, others don't. Using a memory safe language, exploit mitigations, fine-grained sandboxing within applications, better cryptographic primitives etc. doesn't increase UI complexity and improves security.
1
Coarse-grained isolation defined by the user is valuable. It's complementary to defending components against remote exploitation and providing fine-grained isolation within applications. They aren't alternative approaches but rather things that go well together.