From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOZkj-0004aZ-FW for qemu-devel@nongnu.org; Mon, 23 May 2011 14:21:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOZki-0002H7-Ab for qemu-devel@nongnu.org; Mon, 23 May 2011 14:21:17 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:49376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOZki-0002Fh-5D for qemu-devel@nongnu.org; Mon, 23 May 2011 14:21:16 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NI9Umc030697 for ; Mon, 23 May 2011 12:09:30 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NILcvf148838 for ; Mon, 23 May 2011 12:21:41 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NIKF0B010661 for ; Mon, 23 May 2011 12:20:15 -0600 Message-ID: <4DDAA55E.5000701@us.ibm.com> Date: Mon, 23 May 2011 14:20:14 -0400 From: Corey Bryant MIME-Version: 1.0 References: <4DD6B777.9020800@us.ibm.com> <4DD6C424.1020104@codemonkey.ws> <4DDA6EFA.9040501@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Blue Swirl , Anthony Liguori , Tyler C Hicks , qemu-devel@nongnu.org On 05/23/2011 11:24 AM, Markus Armbruster wrote: > Kevin Wolf writes: > >> Am 20.05.2011 21:53, schrieb Blue Swirl: >>> On Fri, May 20, 2011 at 10:42 PM, Anthony Liguori wrote: >>>> On 05/20/2011 02:25 PM, Blue Swirl wrote: >>>>> >>>>> On Fri, May 20, 2011 at 9:48 PM, Corey Bryant wrote: >>>>>> >>>>>> sVirt provides SELinux MAC isolation for Qemu guest processes and their >>>>>> corresponding resources (image files). sVirt provides this support >>>>>> by labeling guests and resources with security labels that are stored >>>>>> in file system extended attributes. Some file systems, such as NFS, do >>>>>> not support the extended attribute security namespace, which is needed >>>>>> for image file isolation when using the sVirt SELinux security driver >>>>>> in libvirt. >>>>>> >>>>>> The proposed solution entails a combination of Qemu, libvirt, and >>>>>> SELinux patches that work together to isolate multiple guests' images >>>>>> when they're stored in the same NFS mount. This results in an >>>>>> environment where sVirt isolation and NFS image file isolation can both >>>>>> be provided. >>>>> >>>>> Very nice. QEMU should use this to support privilege separation. We >>>>> already have chroot and runas switches, a new switch should convert >>>>> all file references to fd references internally for that process. If >>>>> this can be made transparent, this should even be the default way of >>>>> operation. >>>> >>>> You mean, QEMU starts up, opens all disk images, reinvokes itself in a >>>> confined context, and then passes fds to the child? >>> >>> And exit after that, or do the same without forking. >>> >>> This wouldn't work now for the native CDROM devices which need to >>> reopen the device. For that, an explicit reopen method could be added. >>> The method could even chat with the privileged process to get that to >>> do the reopening, but I'd leave that to libvirt and fail without it >>> for plain QEMU. >> >> There are more cases where we reopen the image file. One example is the >> 'commit' monitor command which temporarily reopens the backing file r/w. >> Or Christoph's patch that allows guests to toggle the write-cache >> enabled bit. Same for live snapshots. So we'll need a solution for them >> before doing anything like this. >> >> And breaking qemu without libvirt isn't really an option for me. > > Reopening files is evil. Sometimes flaws in the system call API make it > the only option. You can mitigate via /dev/fd/%d, but only on some > systems. The less we reopen, the better. > > An fd: protocol can't easily support reopen. So fail it. This doesn't > break any existing usage. It's just a restriction on the new protocol. > Restrictions can render the new protocol useless in practice, but we're > not "breaking qemu without libvirt" there. > > Perhaps we can make relax the restriction on some system by avoiding the > reopen in a system-dependent way. A lot of great points here. Thanks everyone. I'd like to see if we can go forward with the suggestion of restricting the fd: protocol, at least for the initial patch. Perhaps this first pass at the protocol can limit it to no reopen and no backing file support. Even with this limited support, the fd: protocol can still provide added security for NFS users. Corey