Hacker News Reader

Comment by Titanous | Hacker News Reader

Note that without a separate Linux privilege escalation exploit, running QEMU in a least-privilege "container" for each VM should help stem the bleeding.

View on HN

How often is that how it is run?

All the time if you use libvirt. Also libvirt adds SELinux protection on platforms that support SELinux.

> All the time if you use libvirt.

Does it? Afaik libvirt requires AppArmor/SELinux for this.

cgroups and SELinux protections are separate. See: https://libvirt.org/cgroups.html Also: https://libvirt.org/drvqemu.html#security

But cgroups do not provide isolation, just better resource management.

If you bother to read the second link I posted, you'll see that cgroups does both (some) isolation and resource management. It's a layered scheme however and you absolutely should be using SELinux which is where the really comprehensive confinement happens.

I read both links, and the "isolation" provided by cgroups alone will not prevent exploitation of this bug (or any other, for that matter).

You can flat out wrong about this, as you have been in your other answers. I am an upstream libvirt committer so I do know a fair bit about what libvirt can do. The fact is that the isolation of cgroups will prevent various denial of service bugs, and also access to non-whitelisted devices.

It is nowhere near as comprehensive as SELinux isolation, as I clearly said way up there in my initial response -- which is also the reason why when you use Docker on RHEL, most of the security comes from the additional SELinux protections Red Hat have added.

I agree with you that cgroups protect against denial of service attacks, and that the device whitelist provides some additional security (I actually did not know about the latter, so thanks! TIL). Thinking about it, if you exclusively use block devices for storage, this is a lot better than I expected.

But still, this is nowhere from a "a least-privilege container for each VM" as you suggested.

(I'm a heavy libvirt user myself - thank you for your work on it!)

XenServer runs their version of qemu under a unique unused uid, in a empty chroot and with a separate network namespace. This is the default behavior under XenServer.

Reply on news.ycombinator.com