Conversation

What is your opinion of hypervisors? Couldn't they be considered the next best thing - a compromise between hardware compat and isolation? ^HU

Quote Tweet

Daniel Micay

@DanielMicay

Oct 30, 2018

Replying to @DanielMicay and @Whonix

The Linux kernel is the equivalent of running the entirety of userspace as root in PID 1. There's no isolation or internal security model. It keeps getting worse as more and more complexity is piled on, all of it implemented in C and without any isolation between components.

Replying to

I think the

approach makes a lot of sense. It's a very pragmatic way to deal with this growing problem. Every Linux kernel release is substantially more complicated than the last, with more attack surface and more ways for things to go wrong internally.

Replying to

and

Software is written to run on Linux (desktop, server, Android) though, and a more secure OS without applications for it isn't much good. I think in the long term, the ideal would be having a robust microkernel with drivers, filesystems, etc. divided up and isolated well.

Replying to

and

It needs a way to run existing applications though. The virtualization approach is the most realistic / pragmatic right now. Ideally, I'd like to see a Linux compatibility layer able to avoid having the Linux kernel in the guest, and virtualization could also become optional.

Replying to

and

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.

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.

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

Replying to

Being feature rich isn't at all in conflict with using much safer tools and having a proper security model with internal isolation / security boundaries. Being packed with all kinds of features (many of which are legacy / redundant) just amplifies the problems with the design.

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.

Show replies