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

[Anthony Liguori <anthony@codemonkey.ws>]

Eric Blake <eblake@redhat.com> writes:

> On 03/01/2013 04:05 PM, Anthony Liguori wrote:
>> Eric Blake <eblake@redhat.com> 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.

Opening up files as root and passing the descriptors to an unprivileged
process is more secure than doing open() as an unprivileged process.

The kernel is capable of doing this enforcement.  I don't think it's
reasonable to expect QEMU to never use open() at all.

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

Yes, I understand why this is needed for NFS.  But NFS is a corner case
of the kernel not being able to do it's job.  It doesn't mean we should
circumvent the checking the kernel does and reinvent it all again in
userspace.

> 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 said this when seccomp was first introduced and I'll say it again.
blacklisting open() is a bad idea.  DAC and MAC already exist and solve
this problem.  We've got filesystem namespaces too.

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

I think you're trying to solve the wrong problem (forbidding open()).

Regards,

Anthony Liguori

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