[Freeipa-devel] freeIPA v2: Access control for things not stored in LDAP

[Jason Gerard DeRose]

Dmitri Pal wrote:
> Simo Sorce wrote:
>> On Sun, 2008-11-16 at 20:57 -0700, Jason Gerard DeRose wrote:
>>  
>>> Say we have some operation that should be subject to access control,
>>> but
>>> does not involve something stored in LDAP... how should we enforce the
>>> access control?
>>>     
>>
>> This is a very good question.
>>
>>  
>>> Here's the situation I'm thinking of: v2 has an "env" command that
>>> returns a list of (key, value) pairs describing the configuration
>>> state
>>> (run-time configuration, not the configuration stored in LDAP). In a
>>> client context, the command returns the client environment.  But with
>>> the --server option, it is forwarded to the server and returns the
>>> configuration state on the server.
>>>
>>> Although this configuration data does not contain anything sensitive,
>>> we
>>> might want to restrict who can retrieve the server configuration.
>>>     
>>
>> Yes we may want to restrict it indeed.
>>
>>  
>>> I know our general paradigm is to make LDAP responsible for enforcing
>>> access control. So should IPA be in the business of enforcing access
>>> control in special cases like the "env" command, or should we just
>>> avoid
>>> capabilities like this altogether? Does v1 have any special cases like
>>> this?
>>>     
>>
>> I think we should probably implement ACIs for each function call, and
>> attach default ones at installation time. We should probably think if it
>> make sense to store them in LDAP in this case, although it may also be
>> useful to have different ACIs depending on which server you contact.
>> I am not sure we really want to store them centrally and have them all
>> identical, probably not, it would be too inflexible. Besides they will
>> probably rarely be changed, if we use groups the right way I am sure in
>> most cases people will just need to change group memberships.
>>
>>   
> The ACI approach though consistent with other commands would be too much
> work in v2.
> Is there any simpler way of solving the same problem?

As I don't myself understand ACI's that well yet, my thought was to do
it using groups, something like this:

Each command plugin has an optional "requires_group" attribute. If this
attribute is None (the default in the base class), it means that the
command can be executed by any authenticated user. Otherwise the
attribute is a group name... if the user is a member of this group, they
are allowed to executed the command.

So when a command request comes in over XML-RPC, we do the LDAP bind,
locate the command and check the command's "requires_group" attribute.
If "requires_group" is a <type "str"> and the user is not a member of
this group, we return a 403 Forbidden error.

This group approach would be a small change (I could do it in a day).
Plus, I think we might already need this very feature for the CA
integration plugin (Andrew Wnuk: if you're reading this, can you comment?)

>> We could mimic the LDAP server format so that they will be familiar and
>> easily comparable to LDAP ACIs, we want them to use the same ID used on
>> the LDAP side too. Right now we use DNs in ldap, but we might switchy to
>> UUIDs some day, we should be able to support both (means we probably
>> need a look aside cache for the XML-RPC ACI code that maps kerberos
>> principals to the entry UUID and DN).
>>
>> I would also make the ACIs inheritable, so that they can apply to child
>> objects. To make it easier to apply ACIs it would be nice therefore to
>> group commands in logical units. Make this "group of commands" a parent
>> of the specific commands, and apply the ACI to it.
>>
>> How difficult is it to change the core code to add ACIs and a generic
>> enforcement code that operates before anythng else is called on the
>> server side and returns "permission denied" if the user connecting does
>> not have rights on that command ?
>>
>>   
> Too complex for v2 and a lot of work...
> 
>> Simo.
>>
>>   
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20081117/4ac953d2/attachment.sig>