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
