[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing usin

From: Corey Bryant
Subject: Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd
Date: Mon, 07 May 2012 12:10:34 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0

On 05/01/2012 06:15 PM, Eric Blake wrote:
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).


  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.

If we were to go with this approach, I think the following updates would be required for libvirt. Could you let me know if I'm missing anything?

libvirt tasks:
- Introduce a data structure to store file whitelist per guest
- Add -open-hook-fd option to QEMU command line and pass Unix
  domain socket fd to QEMU
- Create open() handler that handles requests from QEMU to open
  files and passes back fd
- Potentially also handle close requests from QEMU?  Would allow
  libvirt to update XML and whitelist (as well as SELinux labels).
- Canonicalize path names when putting them in whitelist and
  when validating requests from QEMU
- XML updates to track backing chain of qcow2 and qed files
- Update whitelist and XML chain when QEMU monitor commands are
  used to open new files: block-stream, drive-reopen, drive_add,
  savevm, snapshot_blkdev, change

Updates would also be required for SELinux and AppArmor policy to allow libvirt open of NFS files, and allow QEMU read/write (no open allowed) of NFS Files.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]