[Freeipa-devel] Notes and questions for fine-grained read permissions

[Petr Viktorin]

On 09/06/2013 03:59 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> On 09/06/2013 02:46 PM, Rob Crittenden wrote:
>>> Martin Kosek wrote:
>>>> On 09/05/2013 07:48 PM, Rob Crittenden wrote:
>>>>> Petr Viktorin wrote:
>>>>>> Hello,
>>>>>> I have some notes and questions on
>>>>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user
>>>>>> roles to server functions).
>> [...]
>>> Right, I just want to know why it was proposed to add 2 ACIs for every
>>> container.
>>
>> One for the container itself, one for the objects beneath it.
>>
>> I don't see a straightforward way to allow access to both in a single
>> permission. (Currently, permissions need to be at $SUFFIX, so their
>> subtrees are specified by target.)
>>
>> [...]
>
> Right. I'm not sure you need to grant read,search,compare to the
> container. Have you tested that?

To be honest, I assumed some from the bug description. I'll test it. If 
it's not necessary there'll be one ACI per object type.

[...]
>>>>>
>>>>>>
>>>>>> # P.S.
>>>>>>
>>>>>> I believe that we should strive to put our info about default
>>>>>> permissions, containers, settings, and the schema for each plugin in
>>>>>> the
>>>>>> actual plugin module, rather than it all being split across several
>>>>>> ldif/update files. This would make this data more manageable,
>>>>>> introspectable and consistent, expose dependencies between plugins,
>>>>>> and
>>>>>> make it possible to actually write self-contained plugins.
>>>>>> This should be done when the time comes for a new version of the
>>>>>> ldap-updater.
>> [...]
>>>
>>> Well, my alarm bells are going off. This would require some significant
>>> review each and every time any object is updated. Consider how many
>>> times API.txt is overlooked, and it has no security implications.
>>
>> Consider how many times the ldif or update files were overlooked.
>> API.txt is checked during every build, whereas ldif/update files not,
>> and are tedious to check.
>>
>> We can of course add a similar file for ACIs, in fact I was planning to
>> do so. Any changes can be then reviewed both in the source and (like
>> now) in the resulting ldif. Also, the information would be in one place,
>> rather than in ldif (which doesn't apply on upgrades) and in update
>> files.
>> I believe it would actually be better for security.
>
> The plan at the time updates were added was to move absolutely
> everything out of ldif and into updates. It just never happened.

Good to know. Is it still the plan? Do I only need to change the update 
files?

>>> I can't say I'm a fan of programmatic ACI generation.
>>
>> Well, I'm sure not going to write the ACIs for this feature by hand. It
>> would help I could actually polish, commit and integrate the script that
>> generates them.
>> In my book, programmatic generation is much better than copy+paste.
>>
>
> On the other hand, it becomes very easy to just rely on it and not
> closely examine the output.

That is a question of checking the changes. Frankly I don't see that 
much difference between not checking after updates and not checking 
after copy+pasting.
If nothing, the existence of an ACI.txt should remind us that security 
is at stake.
Also, if the objectclasses change this will alert us that ACIs need 
changing as well.

-- 
Petr³