Re: [RFC][PATCH 00/01]qemu VM entrypoints

["Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Fri, Jul 20, 2007 at 03:32:16PM -0400, 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.
> 
> Until then, there seems to be interest in adding MAC controls to control VM
> management operations, such as migrating VMs, or saving/resuming VMs.
> 
> 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.

It could be - if your put the policy at the control API layer instead of
in QEMU itself. One of the roadmap items for the libvirt API is fine grained
MAC on all virtual machine control APIs it exposes. SELinux is the most
likely technology we've thought about using for this task. libvirt itself 
exec's the QEMU or KVM binary, so it may be possible to do a transition at 
that point.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
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/