On Mon, Aug 22, 2011 at 11:29:12AM -0500, Anthony Liguori wrote: > 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. qemu-fe would also not be entirely simple, because it will need to act as a proxy for the monitor, in order to make hotplug work. ie the mgmt app would be sending 'drive_add file:/foo/bar' to qemu-fe, which would then have to open the file and send 'drive_add fd:NN' onto the real QEMU, and then pass the results on back. In addition qemu-fe would still have to be under some kind of restricted security context for it to be acceptable. This is going to want to be as locked down as possible. So I'd see that you'd likely end up with the qemu-fe security policy being identical to the qemu security policy, with the exception that it would be allowed to open files on NFS without needing them to be labelled. So I don't really see that all this gives us any tangible benefits over just allowing the mgmt app to pass in the FDs directly. > But libvirt would still need to parse image files. Not neccessarily. As mentioned below, it is entirely possible to enable the mgmt app to pass in details of the backing files, at which point no image parsing is required by libvirt. Hence my assertion that the question of who does image parsing is irrelevant to this discussion. > >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. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list