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

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

[David Windsor]

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 qemu as found in the kvm-userspace trunk
repository.

Thoughts?

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

[David Windsor]

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.

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
>

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

[David Windsor]

On 7/20/07, James Morris <jmorris@namei.org> wrote:
> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>
> > It could be - if your put the policy at the control API layer instead of
> > in QEMU itself.
>
I think that libvirt may be a bit too high in the virtualization stack
for this control.
What benefits are there for placing such a hook in libvirt vs qemu?
libvirt could still use the vm:entrypoint permission for other types
of VMs it manages.

> Then you can bypass MAC security by invoking qemu directly.
>
>
> - James
> --
> James Morris
> <jmorris@namei.org>
>
> -------------------------------------------------------------------------
> 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
>

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

[Anthony Liguori]

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

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

[Daniel P. Berrange]

On Fri, Jul 20, 2007 at 05:57:29PM -0400, David Windsor wrote:
> On 7/20/07, James Morris <jmorris@namei.org> wrote:
> >On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
> >
> >> It could be - if your put the policy at the control API layer instead of
> >> in QEMU itself.
> >
> I think that libvirt may be a bit too high in the virtualization stack
> for this control.
> What benefits are there for placing such a hook in libvirt vs qemu?
> libvirt could still use the vm:entrypoint permission for other types
> of VMs it manages.

It is quite possible that we need policy at several layers of the virt stack.
It also could be that we're thinking about different aspects of the access 
control for VMs. So here's a little background on what I've considered so 
far in the context of libvirt & in particular how it deals with QEMU...

Currently there are two ways to access libvirt. A local user may use the 
library directly. A remote user may use the library indirectly via the 
libvirt daemon. The libvirt daemon allows connections either via combination 
of an SSH tunnel to its UNIX domain socket, or a SSL/TLS encrypted channel.
In the local, or SSH case permissions are coarse - root has full read-write, 
non-root has readonly. Potentially we could use peer credentials on unix 
domain sockets to do more per-user permissioning. In the TLS case, we each 
client user is identified based on their client  SSL cert. 

We'd like to be able to have fine grained MAC, so one could allow rules like

  - client 'a' can start/stop guest 'X'
  - client 'b' can monitor stats of guest 'Y'
  - client 'c' can define new guests / delete existing guests

We've not really investigated the SELinux side in much detail yet, but my
current thoughts are based on knowledge of the way DBus integrates with
SELinux to do MAC on its clients & their API calls.  In the local user case, 
obviously the UNIX user has a corresponding SELinux domain. In the remote 
case, one could map x509 certificate IDs (the remote user's identify) to 
appropriate local SELinux domains.

The libvirt daemon/driver would need calls out to the SELinux APIs for any
of the ACL checks it needs internally. Policy would ensure than when libvirtd
started any VMs (ie qemu processes), the appropriate domain transition would
take place on exec. Once QEMU is running in appropriate domain, policy would
take care of ensuring it only accessed appropriate disks & network interfaces
defined by the config.

The appealing thing to me about trying to get some form of policy at the 
libvirt layer is that to the outside (ie end users) it could provide a
consistent policy for all the different virt platforms supported by libvirt.
Of course the underlying policy for each virt platform is likely radically
different - qemu we deal with directly, Xen we talk to Xend & hypervisor,
OpenVZ we run openvz command line tools. libvirt is all about providing a
consistent management API for all virtualization platforms. Being able to
provide a consistent MAC model alongside that is really desirable to me and
as I see SELinux expand to apps like DBus, PostgreSQL it seems a no-brainer
to also apply it to libvirt (for Linux platforms).

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

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

[James Morris]

On Sat, 21 Jul 2007, Daniel P. Berrange wrote:

> obviously the UNIX user has a corresponding SELinux domain. In the remote 
> case, one could map x509 certificate IDs (the remote user's identify) to 
> appropriate local SELinux domains.

There is already a mechanism for conveying SELinux labels over the network 
via IPsec.


- James
-- 
James Morris
<jmorris@namei.org>