[libvirt] [Qemu-devel] live snapshot wiki updated

[Eric Blake]

On 07/21/2011 02:38 AM, Jes Sorensen wrote:
> On 07/20/11 11:36, Daniel P. Berrange wrote:
>> On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote:
>>> Pardon, but I fail to see the issue here. If QEMU passes a filename back
>>> to libvirt, libvirt still gets to make the decision whether or not it is
>>> legitimate for QEMU to get that file descriptor or not. It doesn't
>>> change anything wrt who actually opens the file, hence the 'trust' is
>>> unchanged.
>>
>> To make the decision whether the filename from QEMU is valid, we have
>> to parse the master image header data to see if the filename actually
>> matches the backing file required by the image assigned to the guest.
>
> Sorry but that doesn't make any sense. In other words, if someone hacks
> an image and makes it point to a different file, you are going to allow
> the backing file to be opened just because it is listed in the image?

Yes, because the only way someone could hack that image is if they have 
rights to that file in the first place.  And if they have rights to that 
file in the first place, then they also can call qemu-img to modify that 
file, or any other number of modifications - but that's not an 
escalation in privilege, so it is not a security hole.  From the 
security point of view, the problem we're solving here is not whether 
the host's file system is properly secured so that only the right people 
can hack image files in the first place - that problem has to already be 
solved before adding sVirt makes any sense.  Rather, the problem we're 
talking about here is the sVirt security setup - where no guest can 
corrupt the data of any other guest, given that the host is already 
secure.  As long as no one qemu process can open the qcow2 file of 
another guest, then it doesn't matter what other security flaws might be 
found in qemu - you have guaranteed that a single rogue guest-in-qemu 
situation cannot corrupt any other guests, because the rogue process 
cannot hack any images not belonging to the rogue guest.

> To the best of my understanding, the whole idea with selinux attributes
> was to be able to specify which files are allowed to be opened by a
> given process. Mapping this to the libvirt model, it should mean libvirt
> ought to carry a positive list of  files that are allowed to be opened,

Which it does, by reading the metadata of those files prior to the point 
of ever handing those files over to an untrusted process - except in one 
case: right now, libvirt is not validating that a qcow2 file is still in 
a sane state after a qemu process ends.

> rather than relying on what might be written to an image file.

Thank you for persisting - you've found another hole that needs to be 
plugged.  It sounds like you are proposing that after a qemu process 
dies, that libvirt re-reads the qcow2 metadata headers, and validates 
that the backing file information has not changed in a manner unexpected 
by libvirt.  If it has, then the qemu process that just died was 
compromised to the point that restarting a new qemu process from the old 
image is now a security risk.  So this is _yet another_ security aspect 
that needs to be coded into libvirt as part of hardening sVirt.

But it is an independent issue of the need for fd passing.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org