Am 02.05.2012 10:53, schrieb Daniel P. Berrange: > On Wed, May 02, 2012 at 10:20:17AM +0200, Kevin Wolf wrote: >> Am 01.05.2012 22:25, schrieb Anthony Liguori: >>> Thanks for sending this out Stefan. >>> >>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote: >>>> Libvirt can take advantage of SELinux to restrict the QEMU process and >>>> prevent >>>> it from opening files that it should not have access to. This improves >>>> security because it prevents the attacker from escaping the QEMU process if >>>> they manage to gain control. >>>> >>>> NFS has been a pain point for SELinux because it does not support labels >>>> (which >>>> I believe are stored in extended attributes). In other words, it's not >>>> possible to use SELinux goodness on QEMU when image files are located on >>>> NFS. >>>> Today we have to allow QEMU access to any file on the NFS export rather >>>> than >>>> restricting specifically to the image files that the guest requires. >>>> >>>> File descriptor passing is a solution to this problem and might also come >>>> in >>>> handy elsewhere. Libvirt or another external process chooses files which >>>> QEMU >>>> is allowed to access and provides just those file descriptors - QEMU cannot >>>> open the files itself. >>>> >>>> This series adds the -open-hook-fd command-line option. Whenever QEMU >>>> needs to >>>> open an image file it sends a request over the given UNIX domain socket. >>>> The >>>> response includes the file descriptor or an errno on failure. Please see >>>> the >>>> patches for details on the protocol. >>>> >>>> The -open-hook-fd approach allows QEMU to support file descriptor passing >>>> without changing -drive. It also supports snapshot_blkdev and other >>>> commands >>>> that re-open image files. >>>> >>>> Anthony Liguori<aligu...@us.ibm.com> wrote most of these patches. I >>>> added a >>>> demo -open-hook-fd server and added some small fixes. Since Anthony is >>>> traveling right now I'm sending the RFC for discussion. >>> >>> What I like about this approach is that it's useful outside the block layer >>> and >>> is conceptionally simple from a QEMU PoV. We simply delegate open() to >>> libvirt >>> and let libvirt enforce whatever rules it wants. >>> >>> This is not meant to be an alternative to blockdev, but even with blockdev, >>> I >>> think we still want to use a mechanism like this even with blockdev. >> >> What does it provide on top? >> >> This doesn't look like something that I'd like a lot. qemu should be >> able to continue to run no matter what the management tool does, whether >> it responds to RPCs properly or whether it has crashed. You need a >> really good use case for the RPC that cannot be covered otherwise in >> order to justify this. > > Indeed, this solution breaks if you stop or restart libvirtd while > QEMU is running. Restarting libvirt while QEMU is running is something > we must support, since installing RPM updates will restart libvirtd > and we cannot let guests die in this case. > > I would much prefer to see us be able to pass FDs in directly alongside > the disk config as we do for netdev TAP/etc, and for QEMU / kernel to be > fixed so that you do not need to re-open FDs on the fly.
I agree, and this is what -blockdev would give us. Part of why I don't like the RFC (apart from RPCing the management tool being just wrong) is that once again it's trying to take shortcuts and only provide a hack for the urgent need instead of doing it properly and implementing -blockdev. I suspect that if we take something half-baked like this, we will keep being unhappy with the situation in the block layer, but it won't hurt enough any more to actually spend effort on it, so that we'll go another five years with it. Kevin
