Re: [libvirt] RFC: extending sVirt to confine host apps which talk to libvirtd
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 :|