On Wed, 03 Sep 2014, Martin Kosek wrote:
On 09/03/2014 01:02 PM, Alexander Bokovoy wrote:
On Wed, 03 Sep 2014, Martin Kosek wrote:
On 09/03/2014 12:39 PM, Alexander Bokovoy wrote:
On Wed, 03 Sep 2014, Petr Viktorin wrote:
On 09/03/2014 10:17 AM, Martin Kosek wrote:
[...]
Exposing the same data anonymously over compat tree when it is available
only for authenticated users over primary tree isn't secure.


If you check
cn=users,cn=Schema Compatibility,cn=plugins,cn=config
you would see that we only allow attributes we already expose to anonymous as
in the basic permission. So it is not that bad.

For users, yes. I assume we want the others to be authenticated only?
My point was that if we are hiding from anonymous access even the fact
that certain user or group exists

Are we?
I was under impression we've followed the change requested by some our
users to knock down anonymous access completely but I still see

# FIXME: We need to allow truly anonymous access only to NIS data for
# older clients. We need to allow broad access to most attributes only
# to authenticated users

in install/share/default-aci.ldif

Maybe it is time to do so?

Not sure about this FIXME comment, we already show most attributes to
authenticated users only, we only show the very basic POSIX attributes. You can
check yourself with

# ipa permission-find "Read User"
No, my question is not about that. We had this discussion in January
where people were asking about shutting anonymous binds to non-rootDSE.
Do we want to follow that now that we have easy way to manage
permissions and remove anonymous binds by default?

And another request was repeated to me lately at a local security meetup
by one of heavy IPA users: can we make an option to prevent
authenticated users from seeing details of other users? This is a
lock down most welcomed by governmental contractors, I've heard.
With our existing permission scheme we seem to be able to implement
that, isn't it?

4.0.x where your existing clients using non-bound version will stop
authorizing sudo commands. And this issue is huge.

Right, this affects Legacy clients feature, makes our ipa-advise insufficient.
Means we should improve the advices.

ipa-advise would then need to refer to some common system account + it's
password it would bind with. Should we file RFE? Is this a right move?
Yes, we need to file RFE and make recommendations to always have
BINDDN/BINDPW or GSSAPI_SIGN/GSSAPI_ENCRYPT/SASL_AUTH_ID/KRB5_CCNAME/USE_SASL
(see sudoers.ldap and ldap.conf manpages).
--
/ Alexander Bokovoy

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to