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.

>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.