On 05/01/2012 03:53 PM, Anthony Liguori wrote: >> I think (correct me if I'm wrong) libvirt should be aware of any file >> that qemu >> asks it to open. So from a security point of view, libvirt can prevent >> opening a >> file if it isn't affiliated with the guest. > > Right, libvirt can maintain a whitelist of files QEMU is allowed to open > (which is already has because it needs to label these files). Indeed. > The only > complexity is that it's not a straight strcmp(). The path needs to be > (carefully) broken into components with '.' and '..' handled > appropriately. But this shouldn't be that difficult to do. Libvirt would probably canonicalize path names, both when sticking them in the whitelist, and in validating the requests from qemu - agreed that it's not difficult. More importantly, libvirt needs to start tracking the backing chain of any qcow2 or qed file as part of the domain XML; and operations like 'block-stream' would update not only the chain, but also the whitelist. In the drive-reopen case, this means that libvirt would have to be careful when to change labeling - provide access to the new files before drive-reopen, then revoke access to files after drive-reopen completes. In other words, having the -open-hook-fd client pass a command to libvirt at the time it is closing an fd would help libvirt know when qemu has quit using a file, which might make it easier to revoke SELinux labels at that time. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list