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

[INAKOSHI Hiroya]

Hi,

thanks for your analysis.

Daniel P. Berrange wrote:
> 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.

I'm not familier with Qpid. Could you explain its benefit or point me
some documents about it? And how can I use it on libvirt?

>  - Remote usage with IPSec ?

I personally don't like IPSec because it's too rigid. And I don't know
whether it is common. X509, SASL, or password authentication through
secure connection seems simple and good enough.

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

That's true but, as I mentioned in the other e-mail, I'm now
concentrating on AC itself assuming that user-auth has been established.
I don't think user authentication and access control should be tied up
with each other. I mean, it's nice if AC-module can always use uid as a
part of the key for consulting policies, not depending on whether
libvirt is running on a local or remote server.

> 
>> 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);

A simple question. How do you identify what user the remote libvirt
switches to? Do you look up some directory services?

Hiroya

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