[libvirt] Fine grained Access Control in libVirt

[Atsushi SAKAI]

Hi, Dan

Would you explain the difference with sVirt?
The final goal sVirt seems same form me.
(for example, define many security domain etc in .te file.)

Or it just a little changes from sVirt implementation?

Thanks
Atsushi SAKAI


"Daniel P. Berrange" <berrange at redhat.com> wrote:

> 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 :|
> 
> --
> Libvir-list mailing list
> Libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list