3 ms·

> anything valuable on the host is perfectly well accessible to QEMU In a well configured KVM instance QEMU obeys the principle of least privilege as much as p

> anything valuable on the host is perfectly well accessible to QEMU In a well configured KVM instance QEMU obeys the principle of least privilege as much as possible, that is it can only access the resources it needs to do its job. In practical terms, this means QEMU is confined (via SELinux, cgroups, Unix permissions, seccomp) to only access resources for the VM it is running; taking over QEMU does not give you access to "anything valuable on the host". Of course, having remote code execution in QEMU is awful; it can be a base for exploiting a kernel vulnerability to get root access. Luckily this bug would not be exploitable in a production setting.

zurn 7y ago
I think the intersection of conigurations where QEMU is using the SLiRP networking and where it's carefully configured to use the (non-default) sandboxing is pretty small. The sandboxing configs are typically associated with use of libvirt where you'll probably be using tun/tap or some other non-slirp kind of networking.
- bonzini 7y ago
  Exactly, this is why this bug is unlikely to be exploitable in production (OpenStack for example only runs QEMU via Libvirt).
geofft 7y ago
In a production system, it's highly unlikely that there is anything on the host besides the VM. You're not running qemu on one core and an unvirtualized database on another. Amazon is not running an S3 file server on the same physical machine that's being an EC2 host. The only valuable thing is other VMs. And I think that there is no common configuration of OpenStack or libvirt that assigns unique access control labels per VM. Every qemu runs with the same privileges, ergo one exploited qemu can laterally attack another. (But maybe there's something nifty I'm missing?) (Agree that for the use case of desktop virtualization, a good SELinux config can keep it from accessing your browser cookies.)
- mjg59 7y ago
  SVirt will usually use a per-VM label that should inhibit direct lateral interaction.
  - bonzini 7y ago
    FWIW, sVirt is the "code name" for Libvirt's SELinux labeling scheme. It uses SELinux multi-category security to ensure that each QEMU can only access resources destined to one VM.

zurn 7y ago

I think the intersection of conigurations where QEMU is using the SLiRP networking and where it's carefully configured to use the (non-default) sandboxing is pretty small. The sandboxing configs are typically associated with use of libvirt where you'll probably be using tun/tap or some other non-slirp kind of networking.

bonzini 7y ago
Exactly, this is why this bug is unlikely to be exploitable in production (OpenStack for example only runs QEMU via Libvirt).

geofft 7y ago

In a production system, it's highly unlikely that there is anything on the host besides the VM. You're not running qemu on one core and an unvirtualized database on another. Amazon is not running an S3 file server on the same physical machine that's being an EC2 host. The only valuable thing is other VMs. And I think that there is no common configuration of OpenStack or libvirt that assigns unique access control labels per VM. Every qemu runs with the same privileges, ergo one exploited qemu can laterally attack another. (But maybe there's something nifty I'm missing?) (Agree that for the use case of desktop virtualization, a good SELinux config can keep it from accessing your browser cookies.)

mjg59 7y ago
SVirt will usually use a per-VM label that should inhibit direct lateral interaction.
- bonzini 7y ago
  FWIW, sVirt is the "code name" for Libvirt's SELinux labeling scheme. It uses SELinux multi-category security to ensure that each QEMU can only access resources destined to one VM.