qemu-devel
[Top][All Lists]
Advanced

[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: Anthony Liguori
Subject: Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd
Date: Tue, 01 May 2012 17:21:22 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/01/2012 05: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).

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

Would you give QEMU open access or change the way you label to only allow read/write access? I think the later is probably the better approach.

So presumably, you'll need to adjust the sVirt policy too...

You'll need to detect if a file is on NFS too and figure out what the default label is that was given so you can build the rules correctly.

Regards,

Anthony Liguori



reply via email to

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