From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH 00/01]qemu VM entrypoints Date: Sat, 21 Jul 2007 09:21:29 +0300 Message-ID: <46A1A5E9.7000807@qumranet.com> 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 , David Windsor , Joshua Brindle , selinux To: Anthony Liguori Return-path: In-Reply-To: <46A11F1A.2080004-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 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? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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/