[Freeipa-devel] Compat tree permissions

[Alexander Bokovoy]

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