I think github.com/google/gvisor is very cool, but it isn't quite what I want since it's designed to run on top of the Linux kernel on the host. It's close to what I want though: a memory safe Linux kernel API implementation able to run without privileges. It's at least progress.
Conversation
Over the years I saw similar projects come from Google like novm, unfortunately they never graduated beyond proof-of-concept stage.
1
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
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
The user doesn't need to see the internal boundaries. Security improvements not increasing complexity for the user and depending on them to go through the motions and get things right are the best ones. I can't understand the argument you're making at all.
If I have a video call with a contact in a messaging client, having a sandbox for video decoding is very valuable and doesn't require me to do any extra work or cope with extra complexity. Similarly, having per-contact isolation is useful. Chromium's site isolation offers that.
1
Fine-grained isolation can be implemented in different ways. The most common is using OS sandboxing primitives and kernel security ends up being the weak link for well designed sandboxes despite using features to substantially reduce attack surface like a tiny seccomp whitelist.
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
Show replies