From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC][PATCH 00/01]qemu VM entrypoints Date: Fri, 20 Jul 2007 17:53:15 -0500 Message-ID: <46A13CDB.7020900@codemonkey.ws> References: <20070720201101.GC12218@redhat.com> <46A11F1A.2080004@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Joshua Brindle , David Windsor , selinux To: James Morris Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org James Morris wrote: > On Fri, 20 Jul 2007, Anthony Liguori wrote: > > >> James Morris wrote: >> >>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote: >>> >>> >>> >>>> It could be - if your put the policy at the control API layer instead of >>>> in QEMU itself. >>>> >>>> >>> Then you can bypass MAC security by invoking qemu directly. >>> >>> >> You can bypass MAC security by writing your own binary that uses the KVM >> kernel interfaces. >> > > Yep, I was thinking only about qemu. > > I guess you'd have OS policy preventing normal domains from accessing > /dev/kvm (or /dev/lguest etc.), while a security-aware launcher would > enforce access control policy over which domains could launch which disk > images as VMs, and also setup the execution context & fork. > I really think you have to start with the assumption that a guest can access anything that QEMU can access and attempt to build security around that. If you want to restrict what the guest can see, restrict what QEMU can see. At some point, we may do crazy stuff like syscall pass-through in which case, it would be all but impossible to have a "security-aware" launcher. Regards, Anthony Liguori > So, perhaps this would be better done at the libvirt layer (i.e. make > libvirt the object manager). > > > > - James > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/