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

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

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.


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


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