Nova just released a fix for this critical CVE: https://bugs.launchpad.net/nova/+bug/1548450
To summarise, it's a qcow2 backing file exploit. The user writes a malicious qcow2 header to the top of a raw disk, then triggers a bug in Nova which causes it to do format detection.
If you read the bug and comments, you'll see that when I initially reported it I was fairly dismissive of its impact because it's only exploitable through libvirt, and the instance is going to be confined by SELinux. But then Dan B points out that sVirt is going to trust whatever Nova tells it to do and label it appropriately. Cue rapid ramping of severity, and it turns out this allows an unprivileged user to read anything on the host, including all raw block devices.
I'm not sure exactly where, but something in this stack has failed us. Let's be clear a couple of things, though:
1. This is an egregious, stupid bug in Nova, and Nova shouldn't have egregious, stupid bugs.
2. SELinux should prevent obviously bad things from happening, even in the presence of egregious, stupid bugs.
I point that out to head off: 'Well Nova shouldn't do that'. Of course it shouldn't. However, it might, and when it does, I'd like to think that SELinux has its back. It doesn't, though.
As I understand it, sVirt is the mechanism libvirt uses for controlling SELinux. I wonder if the current sVirt model is enough to cover the use case where the thing connecting to libvirt is large enough to have its own serious bugs. Is there any way we could define a sane set of operations independent of Nova?
Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team
Phone: +442070094448 (UK)
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list