From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Windsor Subject: Re: [RFC][PATCH 00/01]qemu VM entrypoints Date: Sun, 22 Jul 2007 13:39:00 -0400 Message-ID: References: <46A22C37.5030004@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , David Windsor , Joshua Brindle , selinux To: Anthony Liguori Return-path: In-Reply-To: <46A22C37.5030004-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> 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 On 7/21/07 11:54 AM, "Anthony Liguori" wrote: > 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? > Yes, technically a process can change its context without executing execve. However, this is generally considered to be bad from a security perspective, as domain transitions should always occur at the boundary of an execve, because of the environmental cleansing that occurs as a result of executing a new binary. This type of behavior, the changing of a process' security context outside of an execve, is called a dynamic transition and violates various useful security properties, namely label tranquility. See http://beyondabstraction.net/2006/04/06/the-environment-environmental-contam ination-and-selinux-part-1 for more information about how SELinux and the linux environment interact. > 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/