[libvirt] sVirt shouldn't let Nova do stupid things

[Matthew Booth]

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160308/91afaee0/attachment-0001.htm>