From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC][PATCH 00/01]qemu VM entrypoints Date: Sat, 21 Jul 2007 10:54:31 -0500 Message-ID: <46A22C37.5030004@codemonkey.ws> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , David Windsor , Joshua Brindle , selinux To: David Windsor 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 David Windsor wrote: > On 7/21/07 2:21 AM, "Avi Kivity" wrote: > > >> 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. >>> >>> >>> >> I guess modifying qemu makes sense if the modification gives you *more* >> permissions. >> >> i.e. you start out just with the ability to access the disk image, and >> then you transition to a new domain that allows you to access some network. >> >> >> Is that what is intended here? >> > > The intent here is to provide some mechanism for a policy-driven transition > to occur when loading a virtual disk. So, an administrator would write > policy for say, a topsecret_vm_t domain, in which the top secret VM can run. > All access requests from this VM would have a source type of topsecret_vm_t > on the host machine. The virtual disk, labeled perhaps as topsecret_disk_t, > would need to be authorized in policy to be an entrypoint into the > topsecret_vm_t domain. This patch proposes a mechanism that allows us to > provide policy driven controls both over which files can be used as a disk > image, and to which domain a qemu process will transition after loading the > disk image. > Can you already write an selinux policy that changes the label of a process when it open()s a different file? Regards, Anthony Liguori > Originally, I thought qemu was the proper place for this type of an > enforcement hook, but libvirt may be more appropriate because qemu could be > launched with a different security context if loading a virtual disk, rather > than having qemu set up the security context of the VM. Thoughts? > > > > ------------------------------------------------------------------------- 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/