[Freeipa-devel] Read access to container entries

[Alexander Bokovoy]

On Mon, 31 Mar 2014, Martin Kosek wrote:
>On 03/31/2014 10:41 AM, Ludwig Krispenz wrote:
>> Hi Petr,
>>
>> we already discussed on IRC, but see some comments below
>> On 03/28/2014 04:11 PM, Petr Viktorin wrote:
>>> Hello,
>>> I'm trying to add ACIs to allow read access to containers, and I need some
>>> input.
>>>
>>> The DS's access control system is not designed to allow access to a single
>>> entry but not its descendants. The [ACI documentation] suggests some ways to
>>> work around it.
>>>
>>> This doesn't work that well for read access in IPA:
>>>
>>> $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA
>>> V2.0" anonymously.
>>> cn=accounts,$SUFFIX needs read access if it or any of its children are to be
>>> listed in a GUI
>>> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be
>>> listed in a GUI
>>> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied
>>>
>>> It's safe to expose IPA's default containers anonymously; all they tell the
>>> user is that they're looking an IPA server.
>>>
>>> The container entries themselves just have cn and an objectClass of
>>> cnContainer, so it's impossible to construct a general targetfilter that
>>> targets them but not any possible descendants.
>>>
>>> I see 3 possible solutions:
>>> 1) File a DS RFE to implement [targetscope]. With that we could have ACIs
>>> that only target a single entry, so admins could manage read access to
>>> containers in the usual way (with permissions).
>>> 2) Add a (objectClass=nsContainer) filter. The problem here is that if this
>>> is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and
>>> other nsContainers under it. For example,
>>> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer.
>>> 3) Add a special attribute to mark "public" containers, and add an ACI with a
>>> filter on that. Something like objectClass=ipaPublicContainer would do.
>> there is one more option
>> 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S
>> or uid=*,cn=accounts,$S
>
>In the past, we tried hard to avoid deny acis and I think we should keep it
>this way. deny ACI is just a hard stop that cannot be overriden by any other
>ACI. If possible, I would prefer to only add allow ACIs.
>
>> In general I think we should implement 1), there will be other scenarios where
>> it could be useful. If something is needed imemdiately I would also prefer 3)
>
>We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature
>is not an option unless it'd be done really fast.
>
>Given Petr's findings, I am thinking that solution based on 3) seems like way
>to go. We would of course only allow objectclass + cn attributes. I am not
>convinced that objectclass like ipaPublicContainer is the right way to go, does
>not sound to me as a standard solution and not something that people would
>assume they need to do when they are adding a custom container.
>
>When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results
>attached) and there were 61 results. Do we really want to update 61 LDAP
>entries and add a custom ipaPublicContainer objectclass to all? Sounds a little
>bit hackish to me.
>
>Would adding following ACIs work?
>
>dn: SUFFIX
>aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass;
>except cn=etc,SUFFIX
>
>dn: cn=etc,SUFFIX
>aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass
>
>As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is
>something we agreed on during DevConf.
>
>With this approach, the only question is what should we do with nsContainer
>based LDAP entries that contains sensitive information. I wonder - is this a
>real situation? Are there many nsContainer LDAP entries with sensitive
>information? Shouldn't we have a rule instead that would recommend using custom
>(not nsContainer) objectclasses to store sensitive information based on cn?
>Otherwise it seems to me a an abuse of nsContainer purpose.
We have trust entries that need absolute protection for any
authenticated read other than from 'trust agents' and 'trust admins' groups.

There are also Kerberos entries that should not be accessible (master
keys, etc). OTP tokens should only be visible to the user itself and
admins. I'm sure there are others too.

-- 
/ Alexander Bokovoy