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