From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBaMl-0003Nz-EO for qemu-devel@nongnu.org; Fri, 01 Mar 2013 19:31:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBaMk-0004Pb-7C for qemu-devel@nongnu.org; Fri, 01 Mar 2013 19:31:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBaMj-0004PS-Ve for qemu-devel@nongnu.org; Fri, 01 Mar 2013 19:31:54 -0500 Message-ID: <513147E4.5030005@redhat.com> Date: Fri, 01 Mar 2013 17:29:24 -0700 From: Eric Blake MIME-Version: 1.0 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> In-Reply-To: <87vc9apt7r.fsf@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2EGFCEATQEFKCMNQRDTSW" Subject: Re: [Qemu-devel] virtio-rng and fd passing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "qemu-devel@nongnu.org" , Stefan Berger This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EGFCEATQEFKCMNQRDTSW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2EGFCEATQEFKCMNQRDTSW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRMUflAAoJEKeha0olJ0NqrHcH/jS5/As/uL/Di76mfPTHxTLo ty6l1W1Dx2M4hpLewilahkFB5uyk5L8Fm6HXLI3WiIzclwBPcgrlGlXW89S2Lzm4 NPXU0GqrgxLiwXgal37huFj5ANADvEiq+w/wY2De1q0VgTHtTQKriUkpyom7VvJR 0Z7dxXAYlWhSTLUzaw1q4IGYapF7IFNE1x9tMugT97oLOvbodbL5bs+yX/X6JrzZ OUcXOAOIpeUGqtZVYaqeunfBr5hTIz3F47/oUOrfL5BP4RxH8gTl7yeBp8DpdbzB J9QrpHxfbEf+LPPDsINF1PW1eJ4a88ztX4n+4lyJf1C28OnvBq3vu8hTQjFDnbI= =cQDq -----END PGP SIGNATURE----- ------enig2EGFCEATQEFKCMNQRDTSW--