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@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org