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

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.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/