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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list