From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBdDq-0001M6-CE for qemu-devel@nongnu.org; Fri, 01 Mar 2013 22:34:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UBdDp-0005TG-3r for qemu-devel@nongnu.org; Fri, 01 Mar 2013 22:34:54 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:47131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UBdDo-0005Sg-WA for qemu-devel@nongnu.org; Fri, 01 Mar 2013 22:34:53 -0500 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 1 Mar 2013 22:34:51 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id E5BEE38C801C for ; Fri, 1 Mar 2013 22:34:48 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r223YmH0244588 for ; Fri, 1 Mar 2013 22:34:48 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r223Ymhf011503 for ; Fri, 1 Mar 2013 22:34:48 -0500 Message-ID: <51317357.60605@linux.vnet.ibm.com> Date: Fri, 01 Mar 2013 22:34:47 -0500 From: Stefan Berger 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> <51314914.5000804@linux.vnet.ibm.com> <87lia6fq2a.fsf@codemonkey.ws> In-Reply-To: <87lia6fq2a.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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" On 03/01/2013 10:17 PM, Anthony Liguori wrote: > Stefan Berger writes: > >> On 03/01/2013 06:59 PM, Anthony Liguori wrote: >>> Eric Blake writes: >>> >>>> On 03/01/2013 04:05 PM, Anthony Liguori wrote: >>>>> Eric Blake writes: >>>>> >>>>>> On 03/01/2013 02:08 PM, Anthony Liguori wrote: >>>>>> >>>>>>>>> You can pass chardevs to the egd backend. It's really not a good idea >>>>>>>>> to pass a fd via rng-rangom. >>>>>> Why not? If you are running a single guest, why can't libvirt pass that >>>>>> one guest an fd instead of making qemu open() the file? >>>>> Why can't QEMU just open(/dev/random)? What's the advantage of libvirt >>>>> doing the open? >>>> sVirt/syscall blacklisting >>>> >>>> Libvirt WANTS to prohibit qemu from using open()/openat(), and instead >>>> get ALL its fds from inheritence across exec() and/or SCM_RIGHTS. In >>>> this way, qemu can be made more secure out of the box, even on file >>>> systems like NFS that lack SELinux labeling. >>> Opening up files as root and passing the descriptors to an unprivileged >>> process is more secure than doing open() as an unprivileged process. >>> >>> The kernel is capable of doing this enforcement. I don't think it's >>> reasonable to expect QEMU to never use open() at all. >> For blacklisting of open() to succeed we would need to at least pass all >> file descriptors into QEMU so that QEMU doesn't need to call open() >> because of the devices it uses. If there are no open() calls left in >> all/most predictable cases then blacklisting open() could be enabled for >> those cases (hopefully all of them). Isn't thos the technical aspect to >> what it comes down to in the end that would let one blacklist open()? > Sandboxing isn't a panacea. The benefit comes from removing unnecessary > interfaces from the attack surface. It doesn't help if you blacklist > and interface but then invent an RPC that replicates it anyway. > > Moving the open validation logic from the kernel to libvirt is *not* > reducing the attack surface. It's simply moving it from one place (the > kernel) to another (libvirt). It depends on what one defends against. If a jail-break succeeds and open() is disabled, then that attack surfaces was effectively reduced. It's hard to say whether opening files within libvirt could then allow new exploits. Stefan