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

[Dmitri Pal]

On 09/06/2013 10:11 AM, Petr Viktorin wrote:
> 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.
>
We probably can add some sort of a check to a patch apply command that
if a file that does ACI part is added or modified in a patch and the
corresponding ACI.txt file is not updated the patch apply operation
would abort.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/