Re: [libvirt] Fine grained Access Control in libVirt
On Fri, Jan 16, 2009 at 12:16:10PM +0900, Atsushi SAKAI wrote: 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.) At this stage sVirt is primarily about protecting guests from each other, and protecting the host from guests. Konrad's suggestions are about protecting guests/hosts from administrators, by providing more fine grained control over what libvirt APIs an admin can invoke on what objects. Both bits of work are required are complementary to each other 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
Re: [libvirt] Fine grained Access Control in libVirt
Daniel summarized my approach nicely. Basically I'm looking at enabling multi-tenancy administration where several admins can exist but they can only see and/or manipulate with resources (VMs, storage, networks) assigned to them. By making use of a generic AC-module approach where actions gets passed through arbitrary complex access control can be enforced since the AC-module could implement/interface different schemes of granting/denying access depending on what enforcing policy wants to be used. One could for example use SELinux as a scheme to enable RBAC and/or tie it together with policies for sVirt. An initial implementation step would be realizing the AC-module foundation and starting with moving out the RW/RO enforcement (currently residing within libvirt.c) as first basic enforcement scheme. Freundliche Grüsse / Best regards Konrad Eriksson Research Software Engineer Trusted Computing / Security Assurance Email: k...@zurich.ibm.com Phone: +41 (0)44 724 84 28 IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland From: Daniel P. Berrange berra...@redhat.com To: Atsushi SAKAI sak...@jp.fujitsu.com Cc: Konrad Eriksson1 k...@zurich.ibm.com, libvir-list@redhat.com Date: 01/16/2009 10:57 AM Subject: Re: [libvirt] Fine grained Access Control in libVirt On Fri, Jan 16, 2009 at 12:16:10PM +0900, Atsushi SAKAI wrote: 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.) At this stage sVirt is primarily about protecting guests from each other, and protecting the host from guests. Konrad's suggestions are about protecting guests/hosts from administrators, by providing more fine grained control over what libvirt APIs an admin can invoke on what objects. Both bits of work are required are complementary to each other 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 :| image/gif smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Fine grained Access Control in libVirt
Hi, 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 IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland image/gif smime.p7s Description: S/MIME Cryptographic Signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fine grained Access Control in libVirt
On Thu, Jan 15, 2009 at 02:39:20PM +0100, Konrad Eriksson1 wrote: 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. In libvirt.c is probably easier ... And abstract out the read-only checks at the same time. Feel free to comment and to come with improvement ideas. All sounds good. There's a wiki page waiting to be filled in with the details here: http://wiki.libvirt.org/page/TodoFineGrainedSecurity Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fine grained Access Control in libVirt
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
Re: [libvirt] Fine grained Access Control in libVirt
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
