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

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 03/01/2013 10:17 PM, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
>
>> On 03/01/2013 06:59 PM, Anthony Liguori wrote:
>>> 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.
>> 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).

It depends on what one defends against. If a jail-break succeeds and 
open() is disabled, then that attack surfaces was effectively reduced. 
It's hard to say whether opening files within libvirt could then allow 
new exploits.

     Stefan