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

[Martin Kosek]

On 09/12/2014 09:35 AM, Petr Viktorin 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)
>
> Removing a default ACI is difficult (read: new code that could go wrong) if we
> want to handle 4.0.2 properly, since installing/upgrading to 4.0.2 will always
> add it back.
> Perhaps we should just say in the release notes that people should remove it
> manually if they're upgrading from 4.0.2?

Well, I am not convinced that everyone reads the release notes, so I would 
rather delete this permission in 4.0.3. Hopefully, there won't be many 4.0.2 
users. It seems as a lesser evil to me than having SSSD clients broken.

>>>> - 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...
>>
>> Martin