<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">Desired is an addition to libVirt that
enables access control on individual actions and data that can be accessed
through the library API.</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">The AC-module could then interface different
backend AC solutions (SELinux, RBAC, ...) or alternatively implement an
internal scheme.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">Normal call path: user -> libvirt.c
-> driver_x</font>
<br><font size=2 face="sans-serif">AC-module injected in call path: user
-> libvirt.c -> AC-module -> driver_x</font>
<br>
<br><font size=2 face="sans-serif">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...).</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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)</font>
<br>
<br><font size=2 face="sans-serif">Feel free to comment and to come with
improvement ideas.</font>
<br>
<br><font size=2 face="sans-serif"><br>
Freundliche Grüsse / Best regards</font>
<table width=100%>
<tr valign=top>
<td width=67% bgcolor=#4477bb><font size=3 color=white face="sans-serif"><b>Konrad
Eriksson</b></font><font size=2 color=white face="sans-serif"><br>
Trusted Computing / Security & Assurance<br>
</font>
<td width=32% bgcolor=#4477bb><img src=cid:_1_06BAEACC06BAE6CC004B018FC125753F><font size=2 color=white face="sans-serif"><b><br>
IBM Zurich Research Laboratory</b><br>
<br>
Saeumerstrasse 4<br>
8803 Rueschlikon<br>
Switzerland </font></table>
<br>