From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOW4V-0004xy-AI for qemu-devel@nongnu.org; Mon, 23 May 2011 10:25:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOW4U-0006CV-5H for qemu-devel@nongnu.org; Mon, 23 May 2011 10:25:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOW4T-0006CP-RP for qemu-devel@nongnu.org; Mon, 23 May 2011 10:25:26 -0400 Message-ID: <4DDA6EFA.9040501@redhat.com> Date: Mon, 23 May 2011 16:28:10 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4DD6B777.9020800@us.ibm.com> <4DD6C424.1020104@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Blue Swirl Cc: aliguori@us.ibm.com, Tyler C Hicks , Corey Bryant , qemu-devel@nongnu.org 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. Kevin