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

[Stefan Berger]

On 03/01/2013 10:17 PM, Anthony Liguori wrote:
> 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).

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