[Libvir] libvirt daemon UNIX socket auth with PolicyKit

[Daniel P. Berrange]

On Wed, Aug 08, 2007 at 03:42:30PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >Currently our authentication model for local connections is using the basic
> >UNIX file permissions, possibly with a setuid helper (in Xen case only). 
> >It can be summarized as
> >
> > - If app using libvirt is running as root
> >      => full access
> > - Else
> >      => read only access
> >
> >The latter is enforced by fact that in Xen case libvirt_proxy only has impl
> >for a handful of read only APIs, or in non-Xen case that the UNIX domain
> >socket for the daemon /var/run/libvirt/libvirt-sock is mode 0700, while 
> >/var/run/libvirt/libvirt-sock-ro is 0777 & the daemon enforces based on 
> >which
> >socket the client connects to.
> >
> >This is good because it allows non-root to at least monitor guest state
> >while requiring root authentication for actually changing state.
> >
> >This is bad because it requires any app which wants to change state to run
> >as root. ie we are required to launch virt-manager as root to gain ability 
> >to manage local guests.  Problem with this include:
> >
> > - running the entire PyGTK & GTK & X codebase as root is undesirable
> > - no integration with the DBus desktop session (gnome-vfs integartion)
> > - no integration with the GNOME keyring (for VNC server passwords)
> > - redundant (&dangerous) if all you want to do is manage remote libvirt 
> > hosts
> >
> >In summary what I really need for virt-manager is
> >
> >  - Always run as non-root
> >  - Authenticate for local guest management (ie read+write)
> >
> >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 ?
> 
> I'm unclear as to what problem this is solving that couldn't be solved 
> using Unix users and groups.  Add the users who need full access to a 
> Unix group and change the permissions on the r/w socket:
> 
>   srw-rw---- 1 root virtstaff 0 2007-06-29 15:50 
> /var/run/libvirt/libvirt-sock

That either gives a user full access without requiring any password, or
requires that the app run as root. That's just a mild tweaking of the 
status quo. It doesn't allow us to authenticate a non-root user to allow
them access without the app itself being run as root.

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