qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] virtio-rng and fd passing
Date: Fri, 01 Mar 2013 21:17:33 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Stefan Berger <address@hidden> writes:

> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>> Eric Blake <address@hidden> writes:
>>
>>> 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.
>> 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.
>
> For blacklisting of open() to succeed we would need to at least pass all 
> file descriptors into QEMU so that QEMU doesn't need to call open() 
> because of the devices it uses. If there are no open() calls left in 
> all/most predictable cases then blacklisting open() could be enabled for 
> those cases (hopefully all of them).  Isn't thos the technical aspect to 
> what it comes down to in the end that would let one blacklist open()?

Sandboxing isn't a panacea.  The benefit comes from removing unnecessary
interfaces from the attack surface.  It doesn't help if you blacklist
and interface but then invent an RPC that replicates it anyway.

Moving the open validation logic from the kernel to libvirt is *not*
reducing the attack surface.  It's simply moving it from one place (the
kernel) to another (libvirt).

I'd rather the kernel be the one validating open() calls than libvirt.

Regards,

Anthony Liguori

>
>    Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]