From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPL19-0003zh-K2 for qemu-devel@nongnu.org; Tue, 01 May 2012 17:53:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPL17-0008KV-Hx for qemu-devel@nongnu.org; Tue, 01 May 2012 17:53:55 -0400 Received: from mail-qa0-f52.google.com ([209.85.216.52]:59003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPL17-0008IT-DK for qemu-devel@nongnu.org; Tue, 01 May 2012 17:53:53 -0400 Received: by qabj34 with SMTP id j34so15601qab.11 for ; Tue, 01 May 2012 14:53:52 -0700 (PDT) Message-ID: <4FA05B63.3090301@codemonkey.ws> Date: Tue, 01 May 2012 16:53:39 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1335886307-27586-1-git-send-email-stefanha@linux.vnet.ibm.com> <4FA046C6.5080909@us.ibm.com> <4FA0598E.1040408@linux.vnet.ibm.com> In-Reply-To: <4FA0598E.1040408@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: Kevin Wolf , libvir-list@redhat.com, Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org On 05/01/2012 04:45 PM, Corey Bryant wrote: > > > On 05/01/2012 04:25 PM, Anthony Liguori wrote: >> Thanks for sending this out Stefan. >> >> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote: >>> Libvirt can take advantage of SELinux to restrict the QEMU process and >>> prevent >>> it from opening files that it should not have access to. This improves >>> security because it prevents the attacker from escaping the QEMU >>> process if >>> they manage to gain control. >>> >>> NFS has been a pain point for SELinux because it does not support >>> labels (which >>> I believe are stored in extended attributes). In other words, it's not >>> possible to use SELinux goodness on QEMU when image files are located >>> on NFS. >>> Today we have to allow QEMU access to any file on the NFS export >>> rather than >>> restricting specifically to the image files that the guest requires. >>> >>> File descriptor passing is a solution to this problem and might also >>> come in >>> handy elsewhere. Libvirt or another external process chooses files >>> which QEMU >>> is allowed to access and provides just those file descriptors - QEMU >>> cannot >>> open the files itself. >>> >>> This series adds the -open-hook-fd command-line option. Whenever QEMU >>> needs to >>> open an image file it sends a request over the given UNIX domain >>> socket. The >>> response includes the file descriptor or an errno on failure. Please >>> see the >>> patches for details on the protocol. >>> >>> The -open-hook-fd approach allows QEMU to support file descriptor passing >>> without changing -drive. It also supports snapshot_blkdev and other >>> commands >>> that re-open image files. >>> >>> Anthony Liguori wrote most of these patches. I >>> added a >>> demo -open-hook-fd server and added some small fixes. Since Anthony is >>> traveling right now I'm sending the RFC for discussion. >> >> What I like about this approach is that it's useful outside the block >> layer and is conceptionally simple from a QEMU PoV. We simply delegate >> open() to libvirt and let libvirt enforce whatever rules it wants. >> >> This is not meant to be an alternative to blockdev, but even with >> blockdev, I think we still want to use a mechanism like this even with >> blockdev. >> >> Regards, >> >> Anthony Liguori >> > > I like it too and I think it's a better solution than the fd: protocol approach. > > I think (correct me if I'm wrong) libvirt should be aware of any file that qemu > asks it to open. So from a security point of view, libvirt can prevent opening a > file if it isn't affiliated with the guest. Right, libvirt can maintain a whitelist of files QEMU is allowed to open (which is already has because it needs to label these files). The only complexity is that it's not a straight strcmp(). The path needs to be (carefully) broken into components with '.' and '..' handled appropriately. But this shouldn't be that difficult to do. Regards, Anthony Liguori >