[Libvir] PATCH: Updated patches for PolicyKit support
A few weeks back I posted some prototype patches for PolicyKit support to allow the main libvirt daemon socket to be made world-accessible. PolicyKit then can do ACLs on incoming connections, allowing definition of rules which could for example, allow only the user who owns the active X login sesion http://www.redhat.com/archives/libvir-list/2007-August/msg00027.html This is an updated patch which takes account of a change in the PolicyKit XML file syntax between 0.4 and 0.5 releases. The configure.in scripts has been tweaked to automatically disable PolicyKit if pkg-config is not available instead of aborting. The code for getting UNIX socket credentials has been factored out into its own method. There is still only a Linux implementation. I was going to take the code for other OS from DBus, but DBus is currently under a GPL/Academic license options, which is not compatible with LGPL. Fortunately DBus is in middle of re-licensing to X11 style which is LGPL compatible, so in a week or so's time we'll be able to safely take their OS portability code for socket credentials. I short-circuit the logic to always allow root. This allows existing people running libvirt tools as root to continue use without any regressions. There is one small issue still that the default policy I provide only allows the use of read-only connections if the user is logged into to the desktop. This is a partial regression - the admin can edit /etc/PolicyKit/PolicyKit.conf and add a site-local rule allowing all users access, regardless of whether they're in a session. I've spoken with David Zeuthan and he's going to add ability to specify rules for non-session clients in the default policy config files, which will fix this minor regression. Once this is done the libvirt default policy will be identical to current file permission based policy (root == full access, non-root == read only). As I mentioned previously, with this change it is now possible to open a full read-write connection from virt-manager running as non-root. Depending on site policy it will optionally prompt for root password (su style equiv) or the user's password (sudo style equiv) without needing virt-manager itself to gain any elevated privileges. When compiling with PolicyKit support, the default file permissions for both the main & readonly UNIX sockets in the daemon switch to 0777, instead of the previous 0700 & 0777. It is possible to turn off PolicyKit auth in the daemon config file, even if it is compiled in - in which case the default permissions get set back to 0700 & 0777. Although in previous feedback Daniel suggested I leave the LIBVIRTD_AUTH_POLKIT constant compiled in all the time, I feel it is better to remove it when the policykit support is disabled in configure. This removes the need to have extra switch/case statements to explicitly reject LIBVIRTD_AUTH_POLKIT auth, since it will be handle by the 'default:' statement which already has code to reject connections. I've done more extensive testing with virt-manager since my previous patch, and its working very nicely with the new UI which allows multiple hypervisor connections. Instead of asking for the root password up-front at app start time, we now only need ask for it if the user connects to a local HV. If they only ever manage remote connections we don't need to do anything with the local root password. 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 -=|
I guess I'd be +1. What do the Solaris folks think? I wonder if issues of authentication and encryption can be separated out to allow a pluggable libvirt auth API? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Thu, Sep 20, 2007 at 05:14:56PM +0100, Richard W.M. Jones wrote:
I guess I'd be +1. What do the Solaris folks think?
I wonder if issues of authentication and encryption can be separated out to allow a pluggable libvirt auth API?
This is an interesting question. Client authentication with PolicyKit is out-of-band from the main libvirt<->client channel. ie, virt-manager has to talk to DBus and say 'I want to gain credential org.libvirt.manage' and then PolicyKit decides whether to allow it, require a password, require the root password, etc. In my current impl, this has to be done prior to connecting to the daemon. We have no API in libvirt for apps to be told whether they need to authenticate, or gain credentials in some way. So virt-manager just tries to use PolicyKit ahead of time, regardless since it has no way to determine if the server will require it or not. I hate to suggest it, but perhaps rather than re-purposing the existing UNIX domain socket /var/run/libvirt/libvirt-sock or libvirt-sock-ro, I should have added a distinct libvirt-sock-polkit ? That would at least give the client app a way to test for existance ahead of time & thus decide if it needs to request for credentials first. To improve matter's we'd need a way for a client app to provide some form of auth callback when opening a connection, and one or two new messages on the wire to negotiate between client &server. This would probably require a new virConnect variant taking a function pointer arg. But just what the API contract will be is not all that straightforward & would want to be extendable to work with stuff like SASL / GSSAPI. We never really came to any conclusion on this last time.... http://www.mail-archive.com/libvir-list@redhat.com/msg00646.html 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 -=|
On Thu, Sep 20, 2007 at 05:46:07PM +0100, Daniel P. Berrange wrote:
On Thu, Sep 20, 2007 at 05:14:56PM +0100, Richard W.M. Jones wrote:
I guess I'd be +1. What do the Solaris folks think?
I wonder if issues of authentication and encryption can be separated out to allow a pluggable libvirt auth API?
This is an interesting question. Client authentication with PolicyKit is out-of-band from the main libvirt<->client channel. ie, virt-manager has to talk to DBus and say 'I want to gain credential org.libvirt.manage' and then PolicyKit decides whether to allow it, require a password, require the root password, etc. In my current impl, this has to be done prior to connecting to the daemon. We have no API in libvirt for apps to be told whether they need to authenticate, or gain credentials in some way. So virt-manager just tries to use PolicyKit ahead of time, regardless since it has no way to determine if the server will require it or not. I hate to suggest it, but perhaps rather than re-purposing the existing UNIX domain socket /var/run/libvirt/libvirt-sock or libvirt-sock-ro, I should have added a distinct libvirt-sock-polkit ? That would at least give the client app a way to test for existance ahead of time & thus decide if it needs to request for credentials first.
To improve matter's we'd need a way for a client app to provide some form of auth callback when opening a connection, and one or two new messages on the wire to negotiate between client &server. This would probably require a new virConnect variant taking a function pointer arg. But just what the API contract will be is not all that straightforward & would want to be extendable to work with stuff like SASL / GSSAPI.
We never really came to any conclusion on this last time....
http://www.mail-archive.com/libvir-list@redhat.com/msg00646.html
I still think it's a bit premature at this point to extract an auth API. Yes this would be very neat to be able to provide a pluggable system, but IMHO we are only starting to use remote operations, we didn't experience yet with ACL-like for the various operation for domains, we don't have yet a clear notion of identity, so I'm afraid any public API we would push at this point in libvirt may not fit the real need of libvirt based management tools I hope we will see in 1-2 years from now. The work on PolicyKit will help definining the scope and limits of what will be required in term of authentication, and as Dan pointed out when and how we need to do so. To me I +1 the PolicyKit patch, based on the fact that it doesn't require to add and explicit API yet, that it goes in the right direction (getting rid of the proxy for example), and the fact it's important to integrate well with the Desktop when possible. Note that I would not remove the proxy code right now, it might be better to desactivate it if PolicyKit is not found, so we can push new libvirt version to older Linuxes or systems without PolicyKit without breaking the important functionality of being able to monitor as non-root. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, Sep 21, 2007 at 06:05:44AM -0400, Daniel Veillard wrote:
On Thu, Sep 20, 2007 at 05:46:07PM +0100, Daniel P. Berrange wrote:
On Thu, Sep 20, 2007 at 05:14:56PM +0100, Richard W.M. Jones wrote:
I guess I'd be +1. What do the Solaris folks think?
I wonder if issues of authentication and encryption can be separated out to allow a pluggable libvirt auth API?
This is an interesting question. Client authentication with PolicyKit is out-of-band from the main libvirt<->client channel. ie, virt-manager has to talk to DBus and say 'I want to gain credential org.libvirt.manage' and then PolicyKit decides whether to allow it, require a password, require the root password, etc. In my current impl, this has to be done prior to connecting to the daemon. We have no API in libvirt for apps to be told whether they need to authenticate, or gain credentials in some way. So virt-manager just tries to use PolicyKit ahead of time, regardless since it has no way to determine if the server will require it or not. I hate to suggest it, but perhaps rather than re-purposing the existing UNIX domain socket /var/run/libvirt/libvirt-sock or libvirt-sock-ro, I should have added a distinct libvirt-sock-polkit ? That would at least give the client app a way to test for existance ahead of time & thus decide if it needs to request for credentials first.
To improve matter's we'd need a way for a client app to provide some form of auth callback when opening a connection, and one or two new messages on the wire to negotiate between client &server. This would probably require a new virConnect variant taking a function pointer arg. But just what the API contract will be is not all that straightforward & would want to be extendable to work with stuff like SASL / GSSAPI.
We never really came to any conclusion on this last time....
http://www.mail-archive.com/libvir-list@redhat.com/msg00646.html
I still think it's a bit premature at this point to extract an auth API. Yes this would be very neat to be able to provide a pluggable system, but IMHO we are only starting to use remote operations, we didn't experience yet with ACL-like for the various operation for domains, we don't have yet a clear notion of identity, so I'm afraid any public API we would push at this point in libvirt may not fit the real need of libvirt based management tools I hope we will see in 1-2 years from now. The work on PolicyKit will help definining the scope and limits of what will be required in term of authentication, and as Dan pointed out when and how we need to do so.
To me I +1 the PolicyKit patch, based on the fact that it doesn't require to add and explicit API yet, that it goes in the right direction (getting rid of the proxy for example), and the fact it's important to integrate well with the Desktop when possible.
After more thought I withdraw the patch in its current form. I'm not happy with the way client apps have to explicitly talk to PolicyKit ahead of time to ask for credentials even if the libvirt daemon doesn't want/need them. It really needs to integrate with the virConnectOpen process better so we get some form of credential request/callback/failure. This would be much more flexible & suitable for other auth schemes.
Note that I would not remove the proxy code right now, it might be better to desactivate it if PolicyKit is not found, so we can push new libvirt version to older Linuxes or systems without PolicyKit without breaking the important functionality of being able to monitor as non-root.
That is a good point. Should make it possible to pass a flag to configure to disable compilation of the proxy code on OS where its not desired instead. 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 -=|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones