From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvXNF-00061N-6i for qemu-devel@nongnu.org; Mon, 22 Aug 2011 12:29:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvXNE-0002Sd-2T for qemu-devel@nongnu.org; Mon, 22 Aug 2011 12:29:17 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:43539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvXND-0002SZ-WC for qemu-devel@nongnu.org; Mon, 22 Aug 2011 12:29:16 -0400 Received: by yih10 with SMTP id 10so4380967yih.4 for ; Mon, 22 Aug 2011 09:29:15 -0700 (PDT) Message-ID: <4E5283D8.9000309@codemonkey.ws> Date: Mon, 22 Aug 2011 11:29:12 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1314024650-28510-1-git-send-email-coreyb@linux.vnet.ibm.com> <20110822153820.GA4774@lst.de> <20110822162444.GI9456@redhat.com> In-Reply-To: <20110822162444.GI9456@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH v4] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: kwolf@redhat.com, aliguori@us.ibm.com, libvir-list@redhat.com, Corey Bryant , qemu-devel@nongnu.org, Christoph Hellwig On 08/22/2011 11:24 AM, Daniel P. Berrange wrote: > On Mon, Aug 22, 2011 at 05:38:20PM +0200, Christoph Hellwig wrote: >> I'm still totally against this. FD passing is a nice feature for sandboxing, >> but the passing should be between closely cooperating programs. We'll >> need a tool shipped from the qemu source tree to open and set up the >> FDs, and not someone external. With that setup in place we can use >> a protocol similar to the various OpenBSD privilegue separated deaemons >> to also allow reopening / snapshots / etc. >> >> Opening fds in libvirt and passing them into qemu is exactly the wrong way, >> and just cements the current horrors where libvirt duplicates parsing >> of image format headers. > > The primary goal of this work is to allow QEMU to use a file, without > giving it permission to open the file. This lets us cope with the current > limitations of NFS wrt SELinux labelling. Where ordinarily we'd relabel > the disk file to allow QEMU to open them, on NFS we can't do that. So we > setup a SELinux policy that allows QEMU to read any NFS files that it is > passed, but not actually open them. This allows secure use of QEMU with > NFS, without having to solve the NFS + SELinux labelling problems, which > is still a long term ongoing effort by NFS vendors. I think you miss the point Christoph is making. Christoph is suggesting that we have two qemu executables, qemu-fe and qemu-system-x86_64. qemu-fe would be smaller and would carry more rights than qemu-system-x86_64. But I don't think this fixes the problem. Something needs to do dynamic labelling of the backing files to implement a Chinese Wall MAC policy. In order to do that, something needs to parse the image formats. I don't think it makes sense to have qemu-fe do dynamic labelling. You certainly could avoid the fd passing by having qemu-fe do the open though and just let qemu-fe run without the restricted security context. But libvirt would still need to parse image files. Regards, Anthony Liguori > > Whether or not libvirt parses image format headers, is a completely > unrelated. Consider if libvirt did not parse image formats and instead > required the mgmt app to pass in details of all backing files. We still > have the problem of how to securely grant just one QEMU instance access > to the files. This still needs the FD passing support being proposed > here to cope with NFS. > > So the question of whether or not libvirt should be parsing image format > headers is completely irrelevant to acceptability of this FD passing > support. > > Regards, > Daniel