Eric Blake <ebl...@redhat.com> 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
