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

Daniel P. Berrange berrange at redhat.com
Mon Jan 26 15:53:06 UTC 2009


On Mon, Jan 26, 2009 at 04:19:14PM +0100, 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)
> 
> 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).

There are lots of scenarios to consider

 - Direct local API usage. You have the PID, UID & GID of the process
 - Local usage via libvirtd + UNIX sockets. You can get the PID, UID & GID
   of the client end using the SCM_CREDENTIALS message. (see man 7 unix)
 - Remote usage via libvirtd + TCP sockets. Depending on the security &
   encryption settings you may have a SASL username, or a x509 certificate
   CNAME, or both, or neither.
 - Local usage via libvirtd + UNIX sockets + libvirt-qpid. The PID, UID
   & GID of the client end aren't particularly usage, since libvirt-qpid
   is just a demon running as root, which accepts calls on behalf of many
   remote apps. Does QPid provide any identifying info about the entity
   which put the message on the queue.
 - Remote usage with IPSec ?

So there are multiple identifying credentials, in multiple formats, and
need some way to associate this information with a connection.

Applying RBAC to local (non-Daemon) API usage has clear limitations - if
the user running virsh (or equiv) has direct access to the system, then
they could trivially just replace the real virsh with their own virsh
without RBAC. So RBAC usage in the non-Daemon context is only useful 
if the user does not have direct access to the ssytem (eg, virsh is being
invoked on their behalf by another tool, or a constrained environment
where its guarenteed they can't provide their own libraries/binaries.

> 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.

The key question is do we need to pass the client/callers identity at
the time we create the connection object, or is it sufficient to
provide it after the fact with a call like

   virConnectAddSecParam(VIR_SECPARAM_UNIX_UID, getuid());
   virConnectAddSecParam(VIR_SECPARAM_UNIX_GID, getgid());
   virConnectAddSecParam(VIR_SECPARAM_USERNAME, saslUsername);
   virConnectAddSecParam(VIR_SECPARAM_X509_CNAME, saslUsername);

Or do we need to provide this info via some form of callback mechanism,
perhaps via the exiting virConnectCredential struct, which is curently
not used on the server end of remote connections.

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 :|




More information about the libvir-list mailing list