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

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.