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

[Eric Blake]

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.

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

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

signature.asc
Description: OpenPGP digital signature