[Freeipa-devel] Compat tree permissions

[Rob Crittenden]

Alexander Bokovoy wrote:
> 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.
> 

Remember that most of the NIS/legacy systems that would actually use
this are non-Linux so keep that in mind as you tighten things up.
ipa-advise doesn't cover the cases of AIX, Solaris and HP/ux.

rob