[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 <address@hidden> 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  -=|