[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:13:38 -0600 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
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
- Re: [Qemu-devel] virtio-rng and fd passing, (continued)
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Stefan Berger, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Eric Blake, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Eric Blake, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Eric Blake, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing,
Anthony Liguori <=
- Re: [Qemu-devel] virtio-rng and fd passing, Paolo Bonzini, 2013/03/02
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/03
- Re: [Qemu-devel] virtio-rng and fd passing, Eric Blake, 2013/03/04
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/04
- Re: [Qemu-devel] virtio-rng and fd passing, Eric Blake, 2013/03/04
- Re: [Qemu-devel] virtio-rng and fd passing, H. Peter Anvin, 2013/03/04
- Re: [Qemu-devel] virtio-rng and fd passing, Eric Blake, 2013/03/04
- Re: [Qemu-devel] virtio-rng and fd passing, Stefan Berger, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Anthony Liguori, 2013/03/01
- Re: [Qemu-devel] virtio-rng and fd passing, Stefan Berger, 2013/03/01