Re: [Qemu-devel] [libvirt] [PATCH v4] Add support for fd: protocol

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/22/2011 11:24 AM, Daniel P. Berrange wrote:
> On Mon, Aug 22, 2011 at 05:38:20PM +0200, Christoph Hellwig wrote:
>> I'm still totally against this.  FD passing is a nice feature for sandboxing,
>> but the passing should be between closely cooperating programs.  We'll
>> need a tool shipped from the qemu source tree to open and set up the
>> FDs, and not someone external.  With that setup in place we can use
>> a protocol similar to the various OpenBSD privilegue separated deaemons
>> to also allow reopening / snapshots / etc.
>>
>> Opening fds in libvirt and passing them into qemu is exactly the wrong way,
>> and just cements the current horrors where libvirt duplicates parsing
>> of image format headers.
>
> The primary goal of this work is to allow QEMU to use a file, without
> giving it permission to open the file. This lets us cope with the current
> limitations of NFS wrt SELinux labelling. Where ordinarily we'd relabel
> the disk file to allow QEMU to open them, on NFS we can't do that. So we
> setup a SELinux policy that allows QEMU to read any NFS files that it is
> passed, but not actually open them. This allows secure use of QEMU with
> NFS, without having to solve the NFS + SELinux labelling problems, which
> is still a long term ongoing effort by NFS vendors.

I think you miss the point Christoph is making.

Christoph is suggesting that we have two qemu executables, qemu-fe and 
qemu-system-x86_64.  qemu-fe would be smaller and would carry more 
rights than qemu-system-x86_64.

But I don't think this fixes the problem.  Something needs to do dynamic 
labelling of the backing files to implement a Chinese Wall MAC policy. 
In order to do that, something needs to parse the image formats.

I don't think it makes sense to have qemu-fe do dynamic labelling.  You 
certainly could avoid the fd passing by having qemu-fe do the open 
though and just let qemu-fe run without the restricted security context.

But libvirt would still need to parse image files.

Regards,

Anthony Liguori

>
> Whether or not libvirt parses image format headers, is a completely
> unrelated. Consider if libvirt did not parse image formats and instead
> required the mgmt app to pass in details of all backing files. We still
> have the problem of how to securely grant just one QEMU instance access
> to the files. This still needs the FD passing support being proposed
> here to cope with NFS.
>
> So the question of whether or not libvirt should be parsing image format
> headers is completely irrelevant to acceptability of this FD passing
> support.
>
> Regards,
> Daniel