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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
