On 05/01/2012 04:45 PM, Corey Bryant wrote:
On 05/01/2012 04:25 PM, Anthony Liguori wrote:
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
Libvirt can take advantage of SELinux to restrict the QEMU process and
prevent
it from opening files that it should not have access to. This improves
security because it prevents the attacker from escaping the QEMU
process if
they manage to gain control.
NFS has been a pain point for SELinux because it does not support
labels (which
I believe are stored in extended attributes). In other words, it's not
possible to use SELinux goodness on QEMU when image files are located
on NFS.
Today we have to allow QEMU access to any file on the NFS export
rather than
restricting specifically to the image files that the guest requires.
File descriptor passing is a solution to this problem and might also
come in
handy elsewhere. Libvirt or another external process chooses files
which QEMU
is allowed to access and provides just those file descriptors - QEMU
cannot
open the files itself.
This series adds the -open-hook-fd command-line option. Whenever QEMU
needs to
open an image file it sends a request over the given UNIX domain
socket. The
response includes the file descriptor or an errno on failure. Please
see the
patches for details on the protocol.
The -open-hook-fd approach allows QEMU to support file descriptor passing
without changing -drive. It also supports snapshot_blkdev and other
commands
that re-open image files.
Anthony Liguori<aliguori@xxxxxxxxxx> wrote most of these patches. I
added a
demo -open-hook-fd server and added some small fixes. Since Anthony is
traveling right now I'm sending the RFC for discussion.
What I like about this approach is that it's useful outside the block
layer and is conceptionally simple from a QEMU PoV. We simply delegate
open() to libvirt and let libvirt enforce whatever rules it wants.
This is not meant to be an alternative to blockdev, but even with
blockdev, I think we still want to use a mechanism like this even with
blockdev.
Regards,
Anthony Liguori
I like it too and I think it's a better solution than the fd: protocol approach.
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). 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.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list