[Freeipa-devel] #4534: SSSD deref processing fail when entryusn can be read and objectclass doesn't

[Simo Sorce]

On Thu, 2014-09-11 at 20:28 +0200, Martin Kosek wrote:
> On 09/11/2014 05:37 PM, Simo Sorce wrote:
> > On Thu, 2014-09-11 at 17:03 +0200, Martin Kosek wrote:
> >> Hello,
> >>
> >> We have another important issue to resolve. Current FreeIPA 4.0.2 ACI settings
> >> cause older SSSD clients to fail as they get returned an LDAP deref call
> >> results without objectclass attribute and just with entryusn attribute. Details
> >> in https://fedorahosted.org/freeipa/ticket/4534. While I agree SSSD should be
> >> more tolerant in this case, it still breaks old clients which we should prevent.
> >>
> >> There are 2 ways how to fix I currently see:
> >>
> >> 1) Return objectclass for any entry, just like we do with operational attributes
> >>
> >> This would include adding "objectclass" to "System: Read Timestamp and USN
> >> Operational Attributes". However, I am rather cautious about this approach as
> >> even though objectclass does not usually carry a secret information, we could
> >> still leak some information about our DIT to unprivileged user.
> >
> > Our DIT is public and known, I see no problem.
> 
> I rather meant the LDAP tree and it's contents (custom groups, sudo rules, 
> roles, ...).
> 
> I did one more test and found out we cannot do this as it would undermine the 
> ACIs we have right now. As soon as objectclass is allowed globally, ldapsearch 
> returns every object even if no other attribute is returned:
> 
> # ldapsearch -h `hostname` -Y GSSAPI -b cn=pbac,dc=mkosek-fedora20,dc=test
> SASL/GSSAPI authentication started
> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST
> SASL SSF: 56
> SASL data security layer installed.
> ...
> # User Administrators, privileges, pbac, mkosek-fedora20.test
> dn: cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test
> objectClass: top
> objectClass: groupofnames
> objectClass: nestedgroup
> ...
> 
> It would not show any more info before that, but even the list of permissions, 
> privileges and roles along with it's names is a leaked information.
> 
> 
> >> 2) Show objectclass+operational attributes in our Read ACIs
> >> Other way I see is to update *all* our Read permissions allowing reading
> >> objectclass attribute and also allow the chosen LDAP operational attribute.
> >> This would let the LDAP caller to always get either all these discussed
> >> attributes but none at all.
> >>
> >>
> >> Do we want to do this? Any other (better) idea how to approach it?
> >
> > I honestly am not sure I understand the distinction between 1 and 2, can
> > you provide the actual ACIs or a behavior example ?
> >
> > Simo.
> 
> Currently, our ACI allows reading entryusn in any LDAP entry. So user (SSSD) 
> running LDAP deref call gets entryusn from object it does not have a read 
> access to:
> 
> # ldapsearch -h `hostname` -Y GSSAPI -b 
> uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E 
> 'deref=memberof:objectclass,entryusn'
> SASL/GSSAPI authentication started
> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST
> SASL SSF: 56
> SASL data security layer installed.
> ...
> # memberof: <entryusn=845>;cn=replication administrators,cn=privileges,cn=pba
>   c,dc=mkosek-fedora20,dc=test
> 
> # memberof: <entryusn=75>;cn=add replication agreements,cn=permissions,cn=pba
>   c,dc=mkosek-fedora20,dc=test
> ...
> 
> This confuses SSSD (sees entryusn but does not see objectclass attribute) + may 
> give out some information we do not want to give out. Fortunately, bare 
> ldapsearch does not show anything:
> 
> # ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication 
> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test" entryusn
> SASL/GSSAPI authentication started
> SASL username: host/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <cn=replication 
> administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test> with scope subtree
> # filter: (objectclass=*)
> # requesting: entryusn
> #
> 
> # search result
> search: 4
> result: 0 Success
> 
> # numResponses: 1
> 
> 
> The idea behind Option 1 was to add ACI to allow reading objectclass attribute 
> globally, for our entire tree. (as noted above, not an option).
> 
> The idea behind Option 2 was to:
> - remove global ACI allowing reading entryusn (System: Read Timestamp and USN 
> Operational Attributes)
> - update all our Read permissions to allow entryusn
> 
> Then for example, if user (SSSD) is allowed to read RBAC role objects, he would 
> not be able to read either objectclass or entryusn attributes. This means users 
> would be only allowed to read entryusn for objects that they can really read 
> (i.e. for objects where they can read at least objectclass).
> 
> Did that clarify the options?
> 
> Of course, there is still option 3) to close as wontfix and let older SSSDs be 
> incompatible with FreeIPA 4.0+.

No, 3 is definitely not on the table, I would rather do 1, but I guess 2
is the only good way for now ?

Simo.