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.
Conversation
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.
1
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.