-
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KVM: Use SELinux to sandbox the VMM in dom0 #7054
Comments
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. |
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. |
The idea with WebAssembly is this:
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.
👍 |
Is this worth doing? I would expect that a KVM-based Qubes OS would use Spectrum’s VMM (patched Cloud Hypervisor + virtio-GPU) |
That may work for Linux VMs, but AFAIK wouldn't be enough for Windows, no? |
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. |
Actually, this issue still makes sense even if Cloud Hypervisor is used, because SELinux policy is largely agnostic to the VMM in use. |
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.
The text was updated successfully, but these errors were encountered: