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

[Petr Viktorin]

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?

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


-- 
Petr³