KVM: Use SELinux to sandbox the VMM in dom0

[DemiMarie]

How to file a helpful issue

The problem you're addressing (if any)

With KVM-based Qubes OS (#7051), the emulator (QEMU) will run directly in dom0. This is a massive security risk unless the emulator is adequately sandboxed.

The solution you'd like

When KVM is in use, dom0 should have SELinux enforcing, so that libvirtd can use sVirt to sandbox QEMU. While all of the QEMU processes have the same UID, they have incompatible SELinux MCS labels, so SELinux forbids communication between them. SELinux is preferred over AppArmor as SELinux can restrict ioctls, which AppArmor cannot.

The value to a user, and who that user might be

Users who need to use KVM-based Qubes OS will have better security than they would otherwise.

[Rspigler]

Wow, I was not aware of this. Another very strong reason for Xen over KVM. Conceptually, I don't understand why replacing one hypervisor with another would result in this. Could you help explain?

[DemiMarie]

Wow, I was not aware of this. Another very strong reason for Xen over KVM. Conceptually, I don't understand why replacing one hypervisor with another would result in this. Could you help explain?

Xen supports having device emulation run in a separate virtual machine, known as a stubdomain. Qubes OS uses this to sandbox the device emulator.

KVM has no support for this. The emulator is a standard userspace process and uses ioctls to interact with the VM. Theoretically, one could have another VM that the actual device emulation happened in, but this is not supported by any toolkit I am aware of, and I do not believe it is considered practical. Compiling the device emulation logic to WebAssembly is a feasible solution, but nobody has implemented it yet.

[iamahuman]

Compiling the device emulation logic to WebAssembly is a feasible solution, but nobody has implemented it yet.

WebAssembly is still susceptible to (application-side) memory corruption, so I guess it won't bring significant benefits over a SELinux/seccomp sandbox. Well WASI (with its capability-based security) shall be a reasonable sandbox, though.

For PVH (not HVM) equivalent, I've heard good things about Firecracker MicroVM. It's also written in Rust.

[DemiMarie]

Compiling the device emulation logic to WebAssembly is a feasible solution, but nobody has implemented it yet.

WebAssembly is still susceptible to (application-side) memory corruption, so I guess it won't bring significant benefits over a SELinux/seccomp sandbox. Well WASI (with its capability-based security) shall be a reasonable sandbox, though.

The idea with WebAssembly is this:

• The device emulator (QEMU) is compiled to WebAssembly, and then to machine code. Since the source code of QEMU can be assumed not to be malicious, one can assume that the WebAssembly ⇒ machine code translation does not exploit any WebAssembly compiler vulnerabilities.
• The machine code compiled from WebAssembly is guaranteed to maintain certain invariants, even if there is a vulnerability in QEMU.
• The rest of the emulator is written in Rust, and uses the translated QEMU as a static library. The Rust code assumes that the compiled WebAssembly satisfies the aforementioned invariants, but those hold true even if there is a security vulnerability in QEMU. Otherwise, QEMU is considered to be untrusted.

This approach is used at massive scale by Fastly, using the Lucet toolchain. Lucet actually has an even harder task, since they must consider the input WebAssembly to be malicious and thus potentially trying to exploit compiler bugs, whereas in our case we can assume that the WebAssembly code is not itself malicious.

For PVH (not HVM) equivalent, I've heard good things about Firecracker MicroVM. It's also written in Rust.

:+1:

[DemiMarie]

Is this worth doing? I would expect that a KVM-based Qubes OS would use Spectrum’s VMM (patched Cloud Hypervisor + virtio-GPU)

[marmarek]

That may work for Linux VMs, but AFAIK wouldn't be enough for Windows, no?

[DemiMarie]

Cloud Hypervisor supports Windows. It is necessary to install the virtio drivers, but one can do that from either the virtual firmware or from within a nested KVM/QEMU VM.

[DemiMarie]

Actually, this issue still makes sense even if Cloud Hypervisor is used, because SELinux policy is largely agnostic to the VMM in use.