Re: [Qemu-devel] virtio-rng and fd passing

[Eric Blake]

On 03/01/2013 04:05 PM, Anthony Liguori wrote:
> Eric Blake <address@hidden> writes:
> 
>> On 03/01/2013 02:08 PM, Anthony Liguori wrote:
>>
>>>>> You can pass chardevs to the egd backend.  It's really not a good idea
>>>>> to pass a fd via rng-rangom.
>>
>> Why not?  If you are running a single guest, why can't libvirt pass that
>> one guest an fd instead of making qemu open() the file?
> 
> Why can't QEMU just open(/dev/random)?  What's the advantage of libvirt
> doing the open?

sVirt/syscall blacklisting

Libvirt WANTS to prohibit qemu from using open()/openat(), and instead
get ALL its fds from inheritence across exec() and/or SCM_RIGHTS.  In
this way, qemu can be made more secure out of the box, even on file
systems like NFS that lack SELinux labeling.  Right now, if you store
your image files on NFS, then you have to explicitly grant SELinux the
virt_use_nfs boolean, which says that qemu can open() _any_ file on NFS,
even if it is not a file belonging to the guest's disk image.  But if we
can prohibit qemu from calling open(), while still accessing everything
it needs with fd passing, then virt_use_nfs is no longer necessary - and
even if the qemu process is compromised by a rogue guest, the
compromised process cannot access any file to which it does not already
have an fd.

But given the way open() blacklisting works, allowing qemu to
open("/dev/random") while forbidding open("/nfs/...") is much harder
than forbidding all open().  In other words, an all-or-nothing switch is
possible only if qemu consistently uses qemu_open() instead of raw open().

> I understand the reason that fdsets exist (because NFS is stupid and
> doesn't support labeling).  But we aren't doing dynamic labeling of
> /dev/random and I strongly suspect it's not on NFS anyway.
> 
> So why are we trying to pass fds here?

Consistency - how do you write a policy that allows open("/dev/random")
while forbidding open("/nfs/...")?  It's much simpler to forbid open(),
even if /dev/random doesn't have any labeling issues.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature