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

[Martin Kosek]

On 09/12/2014 10:27 AM, 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.
>
>     regards
>     thierry

Hello Thierry,

Thanks for the idea, though I share your skepticism to this approach. If adding 
the operational attributes to our Read ACIs is doable, I would also rather like 
to follow that path.

Martin