On Wed, Jul 20, 2011 at 8:41 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 07/20/2011 11:20 AM, Blue Swirl wrote: >> >> There could still be some issues: >> 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? > That is, as long as libvirt can already accurately read the chain of backing > files from any starting point, then it can hand that entire chain of backing > files (whether by the topmost file name as it does now, or whether by a > series of fds as is being proposed) to qemu. > >> >> This could be handled so that instead of naming the backing file, QEMU >> asks for a descriptor for the backing file by presenting the >> descriptor to main file C, but I think the real solution is that >> libvirt should handle the storage formats completely and it should >> present QEMU with only a raw file like interface (read/write/seek) for >> the data. Then any backing files would be handled within libvirt. >> Performance could suffer, though. > > The monitor interface was not designed to throw the read()/write()/seek() > burden back on libvirt, and indeed that would kill performance so it is a > non-starter idea. All we need for security is the open() burden to be > shifted out of qemu and into libvirt. Obviously the interface should be faster than monitor, for example a pair of sockets with some efficient protocol. Monitor could still be used to set up these. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list