<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/11/2014 10:24 PM, Martin Kosek
wrote:<br>
</div>
<blockquote cite="mid:541204E8.3010006@redhat.com" type="cite">On
09/11/2014 08:49 PM, Simo Sorce wrote:
<br>
<blockquote type="cite">On Thu, 2014-09-11 at 20:28 +0200, Martin
Kosek wrote:
<br>
<blockquote type="cite">On 09/11/2014 05:37 PM, Simo Sorce
wrote:
<br>
<blockquote type="cite">On Thu, 2014-09-11 at 17:03 +0200,
Martin Kosek wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
We have another important issue to resolve. Current
FreeIPA 4.0.2 ACI settings
<br>
cause older SSSD clients to fail as they get returned an
LDAP deref call
<br>
results without objectclass attribute and just with
entryusn attribute. Details
<br>
in <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/4534">https://fedorahosted.org/freeipa/ticket/4534</a>. While I
agree SSSD should be
<br>
more tolerant in this case, it still breaks old clients
which we should prevent.
<br>
<br>
There are 2 ways how to fix I currently see:
<br>
<br>
1) Return objectclass for any entry, just like we do with
operational attributes
<br>
<br>
This would include adding "objectclass" to "System: Read
Timestamp and USN
<br>
Operational Attributes". However, I am rather cautious
about this approach as
<br>
even though objectclass does not usually carry a secret
information, we could
<br>
still leak some information about our DIT to unprivileged
user.
<br>
</blockquote>
<br>
Our DIT is public and known, I see no problem.
<br>
</blockquote>
<br>
I rather meant the LDAP tree and it's contents (custom groups,
sudo rules,
<br>
roles, ...).
<br>
<br>
I did one more test and found out we cannot do this as it
would undermine the
<br>
ACIs we have right now. As soon as objectclass is allowed
globally, ldapsearch
<br>
returns every object even if no other attribute is returned:
<br>
<br>
# ldapsearch -h `hostname` -Y GSSAPI -b
cn=pbac,dc=mkosek-fedora20,dc=test
<br>
SASL/GSSAPI authentication started
<br>
SASL username:
<a class="moz-txt-link-abbreviated" href="mailto:host/ipa.mkosek-fedora20.test@MKOSEK-FEDORA20.TEST">host/ipa.mkosek-fedora20.test@MKOSEK-FEDORA20.TEST</a>
<br>
SASL SSF: 56
<br>
SASL data security layer installed.
<br>
...
<br>
# User Administrators, privileges, pbac, mkosek-fedora20.test
<br>
dn: cn=User
Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test
<br>
objectClass: top
<br>
objectClass: groupofnames
<br>
objectClass: nestedgroup
<br>
...
<br>
<br>
It would not show any more info before that, but even the list
of permissions,
<br>
privileges and roles along with it's names is a leaked
information.
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">2) Show objectclass+operational
attributes in our Read ACIs
<br>
Other way I see is to update *all* our Read permissions
allowing reading
<br>
objectclass attribute and also allow the chosen LDAP
operational attribute.
<br>
This would let the LDAP caller to always get either all
these discussed
<br>
attributes but none at all.
<br>
<br>
<br>
Do we want to do this? Any other (better) idea how to
approach it?
<br>
</blockquote>
<br>
I honestly am not sure I understand the distinction between
1 and 2, can
<br>
you provide the actual ACIs or a behavior example ?
<br>
<br>
Simo.
<br>
</blockquote>
<br>
Currently, our ACI allows reading entryusn in any LDAP entry.
So user (SSSD)
<br>
running LDAP deref call gets entryusn from object it does not
have a read
<br>
access to:
<br>
<br>
# ldapsearch -h `hostname` -Y GSSAPI -b
<br>
uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -E
<br>
'deref=memberof:objectclass,entryusn'
<br>
SASL/GSSAPI authentication started
<br>
SASL username:
<a class="moz-txt-link-abbreviated" href="mailto:host/ipa.mkosek-fedora20.test@MKOSEK-FEDORA20.TEST">host/ipa.mkosek-fedora20.test@MKOSEK-FEDORA20.TEST</a>
<br>
SASL SSF: 56
<br>
SASL data security layer installed.
<br>
...
<br>
# memberof: <entryusn=845>;cn=replication
administrators,cn=privileges,cn=pba
<br>
c,dc=mkosek-fedora20,dc=test
<br>
<br>
# memberof: <entryusn=75>;cn=add replication
agreements,cn=permissions,cn=pba
<br>
c,dc=mkosek-fedora20,dc=test
<br>
...
<br>
<br>
This confuses SSSD (sees entryusn but does not see objectclass
attribute) + may
<br>
give out some information we do not want to give out.
Fortunately, bare
<br>
ldapsearch does not show anything:
<br>
<br>
# ldapsearch -h `hostname` -Y GSSAPI -b "cn=replication
<br>
administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test"
entryusn
<br>
SASL/GSSAPI authentication started
<br>
SASL username:
<a class="moz-txt-link-abbreviated" href="mailto:host/ipa.mkosek-fedora20.test@MKOSEK-FEDORA20.TEST">host/ipa.mkosek-fedora20.test@MKOSEK-FEDORA20.TEST</a>
<br>
SASL SSF: 56
<br>
SASL data security layer installed.
<br>
# extended LDIF
<br>
#
<br>
# LDAPv3
<br>
# base <cn=replication
<br>
administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test>
with scope subtree
<br>
# filter: (objectclass=*)
<br>
# requesting: entryusn
<br>
#
<br>
<br>
# search result
<br>
search: 4
<br>
result: 0 Success
<br>
<br>
# numResponses: 1
<br>
<br>
<br>
The idea behind Option 1 was to add ACI to allow reading
objectclass attribute
<br>
globally, for our entire tree. (as noted above, not an
option).
<br>
<br>
The idea behind Option 2 was to:
<br>
- remove global ACI allowing reading entryusn (System: Read
Timestamp and USN
<br>
Operational Attributes)
<br>
- update all our Read permissions to allow entryusn
<br>
<br>
Then for example, if user (SSSD) is allowed to read RBAC role
objects, he would
<br>
not be able to read either objectclass or entryusn attributes.
This means users
<br>
would be only allowed to read entryusn for objects that they
can really read
<br>
(i.e. for objects where they can read at least objectclass).
<br>
<br>
Did that clarify the options?
<br>
<br>
Of course, there is still option 3) to close as wontfix and
let older SSSDs be
<br>
incompatible with FreeIPA 4.0+.
<br>
</blockquote>
<br>
No, 3 is definitely not on the table, I would rather do 1, but I
guess 2
<br>
is the only good way for now ?
<br>
<br>
Simo.
<br>
</blockquote>
<br>
Yeah - 1) would be easy to implement, but it would be a step back
in our ACI model (global allowing ACI again...).
<br>
<br>
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.
<br>
<br>
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...
<br>
</blockquote>
<br>
Hello,<br>
<blockquote>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.<br>
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').<br>
<br>
I honestly do not like this option but in case changing aci
definitions is too risky/complex it is an option.<br>
<br>
regards<br>
thierry<br>
<br>
</blockquote>
<blockquote cite="mid:541204E8.3010006@redhat.com" type="cite">
'<br>
Martin
<br>
<br>
_______________________________________________
<br>
Freeipa-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a>
<br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a>
<br>
</blockquote>
<br>
</body>
</html>