[libvirt] Re: [Patch][RFC] Fine grained access control in libvirt by rbac (0/3)
INAKOSHI Hiroya
inakoshi.hiroya at jp.fujitsu.com
Thu Jan 29 07:47:34 UTC 2009
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
More information about the libvir-list
mailing list