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

[Lukas Slebodnik]

On (11/09/14 22:24), Martin Kosek wrote:
>On 09/11/2014 08:49 PM, Simo Sorce wrote:
>>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.
>
>Yeah - 1) would be easy to implement, but it would be a step back in our ACI
>model (global allowing ACI again...).
>
>Something based on 2) is the only approach that I have in mind right now and
>that would work. It also looks as the right thing to do as then with changing
>visibility of objects by our permission system, visibility of entryusn would
>change too.
>
Not just entryUSN. We need also to change visibility of modifyTimestamp.
SSSD tries to dereference following atributes:
                       objectClass,cn,gidNumber,member,modifyTimestamp,entryUSN
And here is almost equivalent version wit command line ldapsearch.

ldapsearch -Y GSSAPI -h ipa.host.name \
  -E deref=memberOf:objectClass,cn,gidNumber,member,modifyTimestamp,entryUSN \
  -b +"uid=admin,cn=users,cn=accounts,dc=idm,$BASE_DN" "(objectClass=*)" \
  objectClass cn userPassword gidNumber member ipaNTSecurityIdentifier \
  modifyTimestamp entryUSN

//snip

  # memberOf: <modifyTimestamp=20140910134956Z>;<entryUSN=1383>;cn=replication
   administrators,cn=privileges,cn=pbac,dc=idm,dc=example,dc=test

  # memberOf: <modifyTimestamp=20140910133410Z>;<entryUSN=153>;cn=add replicati
   on agreements,cn=permissions,cn=pbac,dc=example,dc=test

LS