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

Simo Sorce ssorce at redhat.com
Fri Sep 12 14:36:02 UTC 2014


On Fri, 2014-09-12 at 10:27 +0200, thierry bordaz wrote:
> On 09/11/2014 10:24 PM, 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.
> >
> > Programatically it should not be difficult to do, we could add these 
> > attributes by default to all read permissions which have allow 
> > objectclass attribute so we would not have to update all our read 
> > permissions by hand...
> 
> Hello,
> 
>     I was thinking to an other option that is looking more as a hack. It
>     is to relax the aci checking (for a given list of attributes) in
>     deref plugin.
>     For example, if a user has access to at least one of the requested
>     attribute (e.g. entryusn), in the deref req, then the derefenced
>     entry could be returned with additional attributes (given in the
>     deref plugin config.: 'objectclass', 'cn').
> 
>     I honestly do not like this option but in case changing aci
>     definitions is too risky/complex it is an option.

NACK, it would make figuring out what a user has access to a nightmare,
you'd be calling CVEs :-)

Simo.






More information about the Freeipa-devel mailing list