[Freeipa-devel] Read access to container entries

[Martin Kosek]

On 03/31/2014 12:52 PM, Alexander Bokovoy wrote:
> 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.

Note that this ACI would only allow access to nsContainer based entries + only
to CN + ObjectClass attributes, i.e. not to any keys present in such entry for
example.

Speaking of Trusts, trust data are in

cn=<AD domain>,cn=ad,cn=trusts,SUFFIX

and none of the subentries has nsContainer object class.

Authenticated user would only see that there is cn=ad,cn=trusts,SUFFIX
container but nothing else (he does see that already).

> There are also Kerberos entries that should not be accessible (master
> keys, etc).

Not nsContainer objetclass, not even a cn attribute - we are safe there.

OTP tokens should only be visible to the user itself and
> admins. I'm sure there are others too.

OTP data are in cn=otp,SUFFIX.

Only cn=otp is a nsContainer entry so anonymous users would only see that this
container exists. Real token data are in ipatokenuniqueid=<id>,cn=otp,SUFFIX
which uses ipaToken* objectclasses, not nsContainer.

Martin