Re: [Qemu-devel] live snapshot wiki updated

[Eric Blake]

On 07/20/2011 12:00 PM, Blue Swirl wrote:
> > > Let's have files A, B, C etc. with backing files AA etc. How would
> > > libvirt know that when QEMU wants to write to file CA, this is because
> > > it's needed to access C, or is it just trickery by a devious guest to
> > > corrupt storage?
> >
> > The fix for CVE-2010-2238 already deals with this: if primary image C refers
> > to backing file CA of raw format, but does not state what file format CA
> > contains, then a malicious guest can modify the contents of CA to appear to
> > be yet another qcow2 image.  At which point, if libvirt follows the backing
> > file specified in CA, then yes, the malicious guest really can cause libvirt
> > to expose arbitrary file CB for manipulation by the guest.  But that
> > security hole was already plugged - by default, libvirt refuses to probe
> > backing files parsed from qcow2 headers for file format, but instead
> > requires the outer qcow2 header to also include the a file format
> > designation for the backing file.  At which point, you then have a safe
> > chain: if C refers to CA, then libvirt knows that both C and CA are
> > essential to the storage presented by giving qemu the file name C, and the
> > guest will already be modifying CA, but there is no storage corruption
> > involved.
>
> But what if CA is accessed even if C is not? For example, QEMU opens C
> (to determine CA and write new information about the path), closes it
> and then requests CA?

Why is qemu trying to access CA?

Either because CA was mentioned as a backing file for C (in which case 
libvirt already knows about it, because either libvirt handed C to qemu 
at startup time after already parsing C's headers to learn that CA is a 
backing file, or because libvirt called the snapshot_blkdev command with 
the intent of having qemu populate CA with C as its backing file), or 
because qemu has a bug (in which case, libvirt should refuse the access 
to CA).

Libvirt is already perfectly capable of tracking all files that qemu 
might need to access, and whether it is qemu or libvirt that does the 
open() of those files, we can still have libvirt validate whether each 
request for a file makes sense given the context of all previous files 
in use from the time the qemu command line was invoked and across all 
monitor commands in the meantime.

On non-NFS solutions, where every file can have a SELinux label, then 
the security is then present by merely having libvirt relabel all such 
files to a unique label for that particular qemu process, and SELinux 
merely enforces that qemu cannot open() anything but what libvirt has 
already labeled.  And since libvirt already knows which files to label 
in the non-NFS scenario, it already knows which fds to pass in the NFS 
scenario, at which point the ability to prevent qemu from open()ing an 
NFS file is a security enhancement.

Your question about qemu wanting to use CA is thus answered 
independently of whether the fd management solution is solved by libvirt 
handing an fd for CA to qemu prior to any monitor command where qemu 
will then need to use CA, or whether qemu is taught to asynchronously 
ask libvirt to open an fd for CA on qemu's behalf.  The answer is that 
libvirt already tracks whether qemu should access CA, and just needs a 
way to enforce that knowledge.  The enforcement already exists for 
non-NFS via SELinux labels, and the proposal to add fd handling will 
expand that enforcement to also cover NFS.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org