QEMU escape mitigations

[simal]

Hi all,

AFAIK latest Proxmox VE includes fixes for all known QEMU escapes out there, however I am interested in mitigations that can be implemented to prevent an attacker who would find and exploit a new QEMU vulnerability to attack other guests, or the host.

In this youtube video, an QEMU developer mentions 3 mitigations:
- run QEMU as an unprivileged user
- run QEMU with seccomp
- run QEMU with Mandatory Access Control (either SELinux or Apparmor)

But it looks like Proxmox VE runs QEMU as root, and does not use seccomp nor Apparmor for virtual machines. An attacker who manages to exploit and escape from QEMU would get root access on the host. Furthermore in a Proxmox cluster SSH keys are distributed across all servers, an attacker who gets root access on one server can SSH as root to all servers in the cluster.

I did not find configuration options in Proxmox VE documentation related to the 3 mitigations above, is there any way to tighten Proxmox VE cluster security?

All best

 

[t.lamprecht]

Hi,

- run QEMU as an unprivileged user

This is the most sensible one, and we planned to look into it more closely and implemented in the future, albeit it may need some accustoming from users and may be opt-in, as it basically mostly relevant if you allow untrusted users onto a system (e.g., for hosting companies), for others it often only adds a lot of pain to manage while not providing that much benefit (an attacker would only require an extra step, with enough time that may happen too).

- run QEMU with seccomp
- run QEMU with Mandatory Access Control (either SELinux or Apparmor)

Those can help a bit, but for QEMU it's somewhat moot, if you do not trust the KVM in kernel why trust the MAC?
But we'll definitively look at those things and enable sensible and actual effective measurements in the future.

I did not find configuration options in Proxmox VE documentation related to the 3 mitigations above, is there any way to tighten Proxmox VE cluster security?

Update frequently, we patch the actual source of the issue, i.e., issues in the kernel or QEMU fast and deploy updates regularly.
Note that guest to host root break-outs are rather rare and often need a very specific configuration.

 

[simal]

Hi Thomas, thanks for your answers!

Re MAC the rationale would be the following: indeed a vulnerability in the KVM kernel module is severe and MAC won't be any help. However historically most of the KVM/QEMU VM escapes exploited vulnerabilities in userspace QEMU. QEMU does most of the virtual devices emulation and has a larger attack surface than the KVM kernel modules.

Mitigations won't stop an attacker from gaining control to the QEMU process, but it would prevent them from attacking other guests or the host itself.

 

[tcc]

Any progress to share here?