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

[David Windsor <dwindsor-5TQdPaFcblfQT0dZR+AlfA@public.gmane.org>]

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.

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/