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)
Feel free to comment and to come with
improvement ideas.
Freundliche Grüsse / Best regards
Konrad
Eriksson
Trusted Computing / Security & Assurance