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

[Dmitri Pal]

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?


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