From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCZmL-0001gl-VA for qemu-devel@nongnu.org; Mon, 04 Mar 2013 13:06:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCZmC-0003PO-9n for qemu-devel@nongnu.org; Mon, 04 Mar 2013 13:06:25 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:51254) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCZmC-0003PH-6v for qemu-devel@nongnu.org; Mon, 04 Mar 2013 13:06:16 -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 ; Mon, 4 Mar 2013 10:27:34 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 884A738C806C for ; Mon, 4 Mar 2013 10:27:30 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r24FRUeG345134 for ; Mon, 4 Mar 2013 10:27:30 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r24FRTMS028099 for ; Mon, 4 Mar 2013 12:27:30 -0300 Message-ID: <5134BD61.3010507@linux.vnet.ibm.com> Date: Mon, 04 Mar 2013 10:27:29 -0500 From: Corey Bryant 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> <51317357.60605@linux.vnet.ibm.com> In-Reply-To: <51317357.60605@linux.vnet.ibm.com> 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: Stefan Berger Cc: "qemu-devel@nongnu.org" , Anthony Liguori On 03/01/2013 10:34 PM, Stefan Berger wrote: > 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 > > Agreed. And this all assumes that libvirt is trusted. The goal is to prevent a malicious qemu guest from opening something that does not belong to it. So we either prevent all qemu open()s with seccomp (which may not be realistic at this point) or we prevent them on a case by case basis with MAC (e.g. prevent qemu from opening files labeled with SELinux type nfs_t) where sVirt does not already have us covered. -- Regards, Corey Bryant