[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Re: [Patch][RFC] Fine grained access control in libvirt by rbac (0/3)


it seems that we share the interest.

Konrad Eriksson1 wrote:
> Yes, we're looking into adding similar form of access control in libvirt.
> The approach we're looking at is to inject AC as a module that 
> intercepts calls from the libvirt core (libvirt.c) to the drivers.
> Reason:
> * AC module can be loaded/unloaded on the fly without need to recompile 
> (can support several different AC-modules and load the appropriate one 
> during "connect").
> * Making use of (semi-stable) API between libvirt core and drivers (also 
> hypervisor/storage/network driver independent)
>    * Being in the call-path also enables AC-module to alter return 
> values (such as filtering lists of VMs/NETs/Storages based on access 
> rights)
> * Minimal code changes in existing libvirt code (basically a one-liner 
> in libvirt.c to inject AC)

Sounds reasonable. Injecting AC without embedding hooks at API entries
is pretty cool. Do you have any implementation?

> What still is an issue is how to correctly get the identity of the user, 
> especially over remote connection.
> I guess you have the same problem? (you're only allowing local usage for 
> now).

Yes, our AC takes effect only when it is invoked locally because uid is
unavailable at a remote site.

> The best way would be to link some user-auth data with the 
> virConnectPtr, but becomes a bit trickier when authentication is done 
> prior (like in remote case) to virConnectOpen.

I agree in that some user-auth mechanisms are necessary, but now I
concentrate on AC-module itself assuming that user-auth is finished.
Daniel gave a concrete idea on user authentication and I find it fine.

> You implemented your own RBAC language to describe the AC-policies.
> Have you looked at possibility to link with already existing RBAC 
> mechanisms for Linux (like SELinux or maybe simpler AC-libs)?

I have some coarse ideas where policies should be given as a SELinux's
policy. It extends libvirt, like sVirt does, so that it calls SELinux
API to make an authenticated user move to a qualified role (domain).
Current sVirt is something different from AC itself though it employs
SELinux. sVirt constrains qemu processes to use just allowed objects,
while AC-module is aimed to constrain users to call just allowed sub
commands on allowd VMs.

>From security point of view, sVirt together with SElinux constraining
libvirt is secure enough to me. So, I don't think it is mandatory that
AC be realized by using SELinux. The main goal of AC in this context is
to prevent differently authorized user from accidentally invoking
unallowed operations. This seems a bit different from keeping the whole
server untainted. So, proprietary implementations don't likely cause a
serious security threat.

Of cause, I understand that SELinux appears an attractive option.



> Freundliche Gru"sse / Best regards
> *Konrad Eriksson*
> Trusted Computing / Security & Assurance
> Email: _kon zurich ibm com_ <mailto:kon zurich ibm com>
> Phone: +41 (0)44 724 84 28 	*
> IBM Zurich Research Laboratory*_
> __www.zurich.ibm.com_ <http://www.zurich.ibm.com/>
> Saeumerstrasse 4
> 8803 Rueschlikon
> Switzerland
> From: 	Syunsuke HAYASHI <syunsuke jp fujitsu com>
> To: 	libvir-list redhat com
> Cc: 	Konrad Eriksson1 <KON zurich ibm com>, berrange redhat com, Atsushi 
> SAKAI <sakaia jp fujitsu com>, INAKOSHI Hiroya 
> <inakoshi hiroya jp fujitsu com>
> Date: 	01/26/2009 11:25 AM
> Subject: 	[Patch][RFC] Fine grained access control in libvirt by rbac (0/3)
> ------------------------------------------------------------------------
> The series of patches introduces a fine grained access control to
> libvirt.  They enable libvirt to enforce users what operations to invoke
> in role-based way.  Our team found that Konrad and Daniel have similar
> interest to ours.  Comments and suggestions are very welcome.
> Patches:
> - Embedding hooks in libvirt (1/3)
> - Access control library (2/3)
> - Example policy files (3/3)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]