Re: [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd

[Anthony Liguori <anthony@codemonkey.ws>]

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