[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]