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 15:03:43 -0500 Message-ID: <46A1151F.7020502@codemonkey.ws> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , 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: > Hi, > > After a bit more discussion about integrating SELinux and KVM, it seems that > there is little interest in adding enforcement hooks to KVM as it stands. > Once KVM gets some type of inter-vm communication mechanism, MAC hooks will > probably be added in that space. > First, a patch like this has to go to qemu-devel. > Until then, there seems to be interest in adding MAC controls to control VM > management operations, such as migrating VMs, or saving/resuming VMs. > Why is this interesting? Is it common to modify applications like this to have additional selinux hooks? Can you give examples? What makes QEMU/KVM special such that it requires userspace selinux hooks? Regards, Anthony Liguori > One particular aspect of VM management which may be nice to control via > SELinux is the loading of a virtual hard disk into a VM. Currently, > administrators would have to rely on file permissions to control which files > could be used as a virtual hard disks. The semantics of file permissions do > not accomplish what is needed here. A domain needs to explicitly get > permission from the policy to both use a file as a virtual disk and to use > the contents of that virtual disk as an "entrypoint" to the new, virtual > machine of a different integrity level. > > Since there is no SELinux permission for this, I have created the vm { > entrypoint } object class/permission pair to represent this type of access. > Policy for allowing domain user_t to load a virtual disk of type > qemu_virtdisk_t would look something like: > > allow user_t qemu_virtdisk_t:file r_file_perms; > type_change user_t qemu_virtdisk_t:vm vm_user_t; > allow qemu_virtdisk_t user_vm_t:vm entrypoint; > > Please note that this patch will only check the entrypoint permission, and > does not actually facilitate transitioning on the type of the virtual disk. > I want some comments before continuing with this approach. > > When loading a virtual disk into a VM, qemu would consult the policy to see > essentially three things: if the current process is allowed to read the > virtual disk file, what the type of the VM should be after loading the disk, > and if the virtual disk is in fact allowed to serve as an entrypoint to the > target domain. > > One problem with this approach is that loading a VM is not an exec-based > operation. Dynamic transitions could be used, but could possibly be avoided > by altering the patch to fork, then re-exec in the target domain. > > This patch applies cleanly to kvm-userspace trunk. > > 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/ > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > ------------------------------------------------------------------------- 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/