[Libvir] libvirt daemon UNIX socket auth with PolicyKit

[Daniel P. Berrange]

On Wed, Aug 08, 2007 at 01:55:15PM +0100, John Levon wrote:
> On Wed, Aug 08, 2007 at 05:22:33AM +0100, Daniel P. Berrange wrote:
> 
> > UNIX domain sockets already provide a way for each end to identify the PID
> > and UID of the other end. This enables the libvirt daemon to determine the
> > identity of the application on the other end. With this information the
> > daemon merely needs to check this identity against some access control policy
> > rules. Where to get/define these rules though ?
> > 
> > Enter PolicyKit.
> > 
> >   http://lists.freedesktop.org/archives/hal/2006-March/004770.html
> >   http://lists.freedesktop.org/archives/hal/2007-June/008815.html
> 
> This is entirely new to me, but I suspect this doesn't have any Solaris
> integration support (yet? I'm asking around about this).

It has only recently had a 'useful' release. It is used by the current HAL
and GNOME Volume Manager releases, so I imagine it'll be getting ported
to Solaris in the near future if its not already under way.

> >   - libvirtd defines two actions it can check called 'libvirt-local-monitor
> >     (read only monitoring of state), and 'libvirt-local-manage' (full
> >     read-write management).
> 
> Good... but I think we need to consider true delegation as well, that
> is, allowing a certain credential to control only one named object. At
> least we need to make sure that's possible in the future without
> breaking anything here.

Yep fine grained mandatory access control per VM/network is definitely 
something I want implemented. It is not clear whether this is something
that would be done in PolicyKit in the future, or whether we'd end up 
using SELinux for it. The latter pretty compelling on Linux because its
a unified MAC system usable across kernel & userspace (DBus, SE-Postgres,
Oddjob to list some examples). Obvious downside is that there would need 
to be a different impl on non-Linux. Fortunatel all these details ought
to be more or less hidden inside libvirt and not be exposed in the public
API aside from a opaque 'token' for labelling the security context of an
object.

> >   - libvirtd use SO_PEERCRED to get the PID of the client
> 
> Solaris doesn't have this, but the more powerful getpeerucred():
> 
> http://docs.sun.com/app/docs/doc/819-2243/6n4i09924?a=view
> http://docs.sun.com/app/docs/doc/819-2243/6n4i099nf?a=view

There's at least 5 different impls of this general context across the
various UNIX OS :-( I've just suggested to David Z that PolicyKit provide
a 'polkit_caller_new_from_socket'  API, so all the OS specific code for
getting a UID from a socket can be isolated in polkicykit libraries rather
than making each individual app re-implement the portability.

> Typically, we would then compare either the process's privilege set or
> the user id. Privileges will likely have to come later but the user ID
> will translate directly into RBAC:
> 
> http://www.samag.com/documents/s=7667/sam0213c/0213c.htm
> 
> Now, it may be the case that we can fit into the Policy Kit framework
> and that work is ongoing, which would make things simple from libvirt
> point of view (only need to replace SO_PEERCRED by getpeerucred for
> now). I will endeavour to find out for you...


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