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.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+. > >> > >> 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. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel