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

[Anthony Liguori]

Eric Blake <address@hidden> writes:

> On 03/01/2013 04:59 PM, Anthony Liguori wrote:
>> 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.
>
> Let's explore that idea a bit further.  What happens if libvirt decides
> to create a new filesystem namespace for qemu, where libvirt unmounts
> all non-local filesystems, as well as any file system that does not
> support SELinux labeling.  Then all remaining filesystems, seen by qemu,
> will enforce SELinux semantics, and we can let qemu open() at will
> because the open will then be guarded by SELinux.  The only remaining
> access is to files to the unmounted file systems, where fd passing from
> libvirt bypasses the fact that qemu can't see the file system.  I could
> see that working, and it would still let us get rid of the selinux
> virt_use_nfs bool while still providing secure NFS out-of-the-box.  And
> your argument is that virtio-rng should be pointed to a character
> device, never an NFS file, and therefore not using qemu_open() is no
> real loss because open() will not be blacklisted, just NFS file systems.
>  Okay, maybe that will work.

A simpler version would be to chroot the QEMU process but sure.

> Still, I think I can come up with a scenario where fd passing makes
> sense.  Consider the case of forensic analysis, where a guest image is
> cloned, and then slight modifications are done on forks of the guest, to
> play out some what-if scenarios.  Let's suppose that I _want_ to have an
> accurate replay of all inputs to the guest - that means that I capture a
> fixed chunk of a true random source once, but then on each variation of
> a guest, I want to replay the _same_ stream of data.  Yes, that is not
> random from the host's perspective - but in forensic analysis, you want
> to eliminate as many variables as possible.  And from the guest's
> perspective, as long as the data was _originally_ captured from a true
> random source, replaying the data once per guest won't violate the
> random expectations within the guest.  Now that means that I want to
> feed virtio-rng with a regular file, not a character device.  Now, where
> do I store that file?  Why not store it alongside my disk images - in
> NFS?  That will only work if qemu can access the random data file; in
> other words, if fd passing is enforced, then accessing a replay stream
> of previously captured random content from NFS storage requires the use
> of qemu_open().

This doesn't work.  /dev/random can return partial reads whereas you
will likely return full reads.  The guest also whitens input from a
hardware rng and that involves using additional sources of entropy.
Basically, you would need 100% deterministic execution for this to work.

There is no valid use-case of rng-random other than using /dev/random.
In fact, it was probably a mistake to even allow a filename to be
specified because it lets people do silly things (like /dev/urandom).

If you want anything other than /dev/random, you should use rng-egd.

Regards,

Anthony Liguori

>
> Maybe you are right that we don't need to blacklist ALL open(), but the
> moment we blacklist NFS open() (such as by the alternative of unmounting
> NFS in the qemu process), then consistency argues that it should still
> be possible to do fd passing.  Should libvirt do fd passing for EVERY
> file?  By your argument, no - only for files living in file systems that
> were blacklisted.  But the point remains - who are you to say that I
> have no valid business opening a guest but feeding that guest's random
> hardware from a file that I store on host's NFS?
>
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org