[Freeipa-devel] Read access to container entries

[Ludwig Krispenz]

On 03/31/2014 12:32 PM, 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.
I agree, in my opinion the access restriction is much clearer if only 
allow is used
>
>> 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.
how fast does it have to be ? If we just can use the same  concept with 
targetscope=[base,one,sub]
implementation should not take too much time, about a week or so, but we 
need to get it accepted by
DS core.

>
> 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
how do you want to specify the "except" ?
>
> 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.
>
> Martin