[Qemu-devel] Re: [kvm-devel] [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori <anthony@codemonkey.ws>]

David Windsor wrote:
> On 7/20/07, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> 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.
>>
> Understood.  This patch started out as a patch to KVM, but eventually
> found its way into userspace/qemu.
>
>> > 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?
>>
> This is interesting because currently there are only DAC controls on
> the loading of virtual hard disks into a qemu virtual machine.
> Further, this patch proposes additional SELinux functionality for
> transitioning the qemu process into the correct TE domain prior to
> launching the VM.
>
> The use case this patch addresses is that of an administrator wanting
> to use KVM/qemu on a server to provide services for subnets of
> computers.  It is important here to ensure that if the server is
> compromised, a qemu process on this compromised server can only use
> virtual disks permitted by policy, otherwise entire subnets of
> computers could be exposed to rogue VMs.
>
> If the qemu process attempting to load the virutal disk does not
> possess the file:read permission on the virtual disk file, access will
> be denied right there.  However, if the process can read the disk
> file, this patch proposes an additional control to see if the virtual
> disk can be used as an entrypoint to the new, target domain.  If the
> vm:entrypoint permission is granted by policy, the qemu process would
> transition to the new domain.

I'm sorry, but this seems a bit mad to me.  Wouldn't you just limit the 
qemu process to not be able to read the virtual disk file either using 
traditional permissions or SELinux based restrictions?

I don't see what you would gain from enforcing this sort of a policy.  
Why would you every want to give QEMU read access to a virtual disk file 
but not allow the VM to access it?

Remember, a VM *is* a process here.  You should restrict QEMU in 
whatever way you want the VM to be restricted.  If you have QEMU 
enforcing security policies for the guest, IMHO you've broken your 
security model.

Regards,

Anthony Liguori

> As it stands, this patch does not perform any transitions upon loading
> a virtual disk.  I think that a transition based on the label of the
> requesting process and the label of the virtual disk is appropriate
> here.  Does anyone else have any thoughts about this?
>
>> What makes QEMU/KVM special such that it requires userspace selinux 
>> hooks?
>>
> qemu itself is special in that it is a userspace backend that is
> widely used with KVM, and the SELinux functionality proposed by this
> patch is significant.  Hopefully this answers your question
> adequately.
>
>> 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@lists.sourceforge.net
>> > 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/
>> _______________________________________________
>> kvm-devel mailing list
>> kvm-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>>
>