On Thu, Jun 09, 2011 at 11:15:48AM -0400, Eric Paris wrote: > On Mon, 2011-06-06 at 15:41 +0100, Daniel P. Berrange wrote: > > What follows is a document outlining some thoughts I've been having > > on extending sVirt to allow confinement of applications which talk > > to libvirtd on the host, primarily focusing on use of SELinux, but > > also allowing a simple non-SElinux RBAC mechanism. > > Are we reinventing a lot of PolicyKit? I don't think policykit does a > good job of using SELinux but it does attempt to solve most of the same > problem you are attempting to solve here. I just want to make sure it > was looked at, even if I like the approach you are taking here more... PolicyKit sounds nice in theory, but in practice I don't believe it can be made to support what I'm proposing. In policykit authorization is performed for a tuple (action, subject) In this, 'action' is a string that identifies the operation being requested, while 'subject' is the client app being checked (either a local UNIX process/user ID or a DBus system bus name in current polkit). libvirt wants to be able to check authorization on a finer level of granularity (action, subject, object) where, action is again just a string identifying the operation, subject is the client app (a local UNIX process/user ID, or a local or remote SELinux context, and 'object' is a managed object like a domain, network, storage pool, identified by UUID, name and/or SELinux context. Polkit 'action' strings must be registered statically in text files in /usr/share/polkit-1, so you can't just munge a object identifier into the 'action' string to get finer grained auth checking. If we used polkit for auth in libvirt, there is no obvious way to scope the checks to individual objects, and no way to include SELinux contexts in the authorization checks. I'm also not convinced that polkit has a scalable architecture when we consider a need to perform several 100's (or even 1000's) of authorization checks in a single API call. Each polkit check requires passing messages from libvirt to DBus system bus to the polkit daemon, and then back again, as opposed to just one or two kernel calls to use something like avc_has_perm() in SELinux. So while, we could, add policy kit support at the granularity of (action, subject) for libvirt API calls, I don't think that could replace the need to provide the fine grained authorization mechanism I describe here. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list