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.t...@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.t...@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.t...@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+.
