From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBctL-0005i3-Lu for qemu-devel@nongnu.org; Fri, 01 Mar 2013 22:13:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBctK-0008RH-8O for qemu-devel@nongnu.org; Fri, 01 Mar 2013 22:13:43 -0500 Received: from mail-oa0-f52.google.com ([209.85.219.52]:37411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBctK-0008RD-20 for qemu-devel@nongnu.org; Fri, 01 Mar 2013 22:13:42 -0500 Received: by mail-oa0-f52.google.com with SMTP id k14so6880078oag.11 for ; Fri, 01 Mar 2013 19:13:41 -0800 (PST) From: Anthony Liguori In-Reply-To: <513147E4.5030005@redhat.com> References: <512FF819.7050505@redhat.com> <87k3pqzy2y.fsf@codemonkey.ws> <513110D3.5030503@linux.vnet.ibm.com> <87d2vig75m.fsf@codemonkey.ws> <51311A13.6030205@redhat.com> <87r4jy90wt.fsf@codemonkey.ws> <51313660.5010001@redhat.com> <87vc9apt7r.fsf@codemonkey.ws> <513147E4.5030005@redhat.com> Date: Fri, 01 Mar 2013 21:13:38 -0600 Message-ID: <87txouv6hp.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] virtio-rng and fd passing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: "qemu-devel@nongnu.org" , Stefan Berger Eric Blake 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