On Thu, Jan 15, 2009 at 02:39:20PM +0100, Konrad Eriksson1 wrote:
After some background research it doesn't look like anyone have
taken on
the task yet to add fine-grained access control to libVirt (only option
right now is R/W or RO mode).
Desired is an addition to libVirt that enables access control on
individual actions and data that can be accessed through the library API.
This could take the form of an AC-module that, based on the identity of
the caller, checks each call and grants/denies access to carry out the
action (could also take parameters in account) and optionally filter the
return data.
The AC-module could then interface different backend AC solutions
(SELinux, RBAC, ...) or alternatively implement an internal scheme.
When looking at the libvirt core and driver framework it seems promising
to inject these kind of call-out hooks either in libvirt.c or between
libvirt.c and the underlying drivers, by doing this AC will be enforced
independent of if a local or remote call is done to libVirt.
I propose an approach to create an AC-module that conforms to the driver
API in libVirt and to inject it in the call-path between libvirt.c and the
driver(s) to enable the AC-module to inspect the call before sending it to
the real driver.
Normal call path: user -> libvirt.c -> driver_x
AC-module injected in call path: user -> libvirt.c -> AC-module ->
driver_x
By doing this it can be loaded/unloaded in run-time and also selectable
what driver paths it should enforce (hypervisor(aka. driver), storage,
network...).
The AC-module can also be made in different flavors for different AC
backend (SELinux, RBAC, internal, ...) solutions and the appropriate
AC-module could be loaded without needing re-compiling.
This approach would also leave a very small footprint in existing libvirt
code (only need to inject AC-module driver after normal drivers has been
loaded)
FYI, I had discussed the alternative approach with Konrad offlist
prior to this thread. Namely, instead of having a driver, layered
in, put a call to something like virCheckAccess() directly into
libvirt.c replacing the RO checks. The complication with doing it
this way, is deciding what information to pass to the virCheckAccess
methods. Obviously the operation name, and then some context for
the object to the be checked. Do we just pass the virDomainPtr
in there. Might need the XML for a new domain create call. Might
want the other virConnectPtr for a migrate call and so on. Seems
like we'd quickly end up having to pass all possible params through
to the virCheckAcces method. At which point it really just becomes
simpler to layer in the checks via the driver API which already
has access to all the neccessary bits of info.
So I think its reasonable to have MAC calls stacked into the driver
API as Konrad illustrates above. The initial impl would just duplicate
our existing RO checks, then we can consider other impls RBAC/SELinux
etc
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|