[Freeipa-devel] Read access to container entries

[Martin Kosek]

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.

Martin
-------------- next part --------------
dn: cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=users,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=services,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=hostgroups,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=alt,dc=mkosek-fedora20,dc=test
dn: cn=ng,cn=alt,dc=mkosek-fedora20,dc=test
dn: cn=automount,dc=mkosek-fedora20,dc=test
dn: cn=default,cn=automount,dc=mkosek-fedora20,dc=test
dn: cn=hbac,dc=mkosek-fedora20,dc=test
dn: cn=hbacservices,cn=hbac,dc=mkosek-fedora20,dc=test
dn: cn=hbacservicegroups,cn=hbac,dc=mkosek-fedora20,dc=test
dn: cn=sudo,dc=mkosek-fedora20,dc=test
dn: cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test
dn: cn=sudocmdgroups,cn=sudo,dc=mkosek-fedora20,dc=test
dn: cn=sudorules,cn=sudo,dc=mkosek-fedora20,dc=test
dn: cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=sysaccounts,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=replicas,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=dna,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=ca_renewal,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=s4u2proxy,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=ipaConfig,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=cosTemplates,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=selinux,dc=mkosek-fedora20,dc=test
dn: cn=usermap,cn=selinux,dc=mkosek-fedora20,dc=test
dn: cn=ranges,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test
dn: cn=pbac,dc=mkosek-fedora20,dc=test
dn: cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test
dn: cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test
dn: cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=retrieve certificate,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=request certificate,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=request certificate different host,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=certificate status,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=revoke certificate,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=certificate remove hold,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=Managed Entries,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=Templates,cn=Managed Entries,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=Definitions,cn=Managed Entries,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=automember,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=CA,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=CAcert,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test
dn: cn=KDC,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=KPASSWD,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=MEMCACHE,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=OTPD,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=HTTP,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=anonymous-limits,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=otp,dc=mkosek-fedora20,dc=test
dn: cn=Realm Domains,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test
dn: cn=trusts,dc=mkosek-fedora20,dc=test
dn: cn=dns,dc=mkosek-fedora20,dc=test
dn: cn=DNS,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test