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

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.


Freeipa-devel mailing list

Reply via email to