[Freeipa-devel] Compat tree permissions

[Alexander Bokovoy]

On Wed, 03 Sep 2014, Martin Kosek wrote:
>On 09/03/2014 02:04 PM, Alexander Bokovoy wrote:
>> 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?
>
>Now it is easy to change different parts of your DIT to different view levels.
>You can easily turn off anonymous access to users without having to disable
>anonymous access on DS cn=config level.
Yep, that's good and need to be documented, we don't have to push people
to cn=config changes like documentation says now.

>
>> 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?
>
>Hm, it would be difficult. SSSD still needs to be able to read all that, so all
>host/FQDN principals need to access that. So you would first need to have a
>hostgroup with all hosts to be able to point permissions at them.
Can we find a better solution here? I.e. make a filter that considers
selfdn and denies access to other user and group accounts unless selfdn
is memberof those groups?

If current ACI syntax doesn't allow this, what can we do to extend the
syntax? I see value in such changes as they will allow also to proceed
to proper containerized setups (multiple trees in the same directory,
invisible to each other).


>>>>>> 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).
>
>Ok, please file the ticket then.
Will do.

-- 
/ Alexander Bokovoy