Conversation

Replying to

and

Over the years I saw similar projects come from Google like novm, unfortunately they never graduated beyond proof-of-concept stage.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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:

github.com

GitHub - tasket/Qubes-VM-hardening: Fend off malware at Qubes VM startup

Fend off malware at Qubes VM startup. Contribute to tasket/Qubes-VM-hardening development by creating an account on GitHub.

Replying to

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.

Replying to

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

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.

6:44 PM · Oct 30, 2018Twitter Web Client

Replying to

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.