On 2/25/22 2:04 AM, William Brown wrote:
>> The benefit is "not wrecking server performance".
>>
>> Even in freeipa, memberOf is not hidden ... I can't think of any situation
where it is hidden ...
>>
>> Today, the inverse risk exists. You can't read member from group hidden, but
you can see user X is memberof: hidden. But we don't seem to worry about
"that" for access controls.
>>
>> Or even nsRoles? We also don't seem to worry about dynamic groups for that.
Or cos templates. Or many of the other ways we generate attributes .... There is ALWAYS a
trade here of exposing infomation via a generated attribute that a user otherwise
couldn't ask for
>>
>> If someone truly was "that worried" about access to this attribute they
need to disable memberOf and this inchain control.
>
> I think that the user sending the request
'(member:1.2.840.113556.1.4.1941:=uid=foo,dc=com)' should get the same result as
if he is iterating through 'member' step by step (e.g sending
'(member=uid=foo,dc=com)' -> G2, then sending '(member=G2)'-> NULL),
the response should only be G2.
>
> I agree that access control that limits access to 'member' but not
'memberof' will reveal a security issue but it is because of badly designed access
control, not because of access control not being enforced.
>
> IMHO we have two aspects to evaluate the benefit of the shortcut: candidate list and
access control.
> The use of the shortcut, gives a faster lookup of the candidates than following the
links.
> Access control is faster while following the links than on a raw list of candidates
(need to recreate the graph).
I think this is not correct, and I think you are thinking about edge case problems that
pretty much don't exist. FreeIPA makes all groups world readable. AD does too. Most
directory systems ship with an access control to allow full read to all groups.
Our memberof already nests groups. So we can look at a user and see all groups they are
memberof, even if we can't read the groups. So we are not disclosing any extra
information here. In freeipa this is also true.
Good point, if majority of deployment do not control access to
'memberof' it is fair to use it. Now knowing that it could violate
access control I think we should propose both. By default, inChain
should use shortcut whenever it is possible (build candidates from
memberof), then use a toggle off this shortcut and build the list from
links and enforce ACI.
Ultimately it's up to you. So long as this feature is disabled by default so it
can't be used by most people, I'm not bothered (bonus marks if you have it behind
a ./configure feature flag so SUSE doesn't even need to compile it). I've given
you my warning about the (serious) performance risks which will only compound with
freeipa's already poor performance in AD trust mode.
Yes use of this feature will be limited (toggle and granted users).
Thanks William for this great discussion and precious feedbacks
thierry
--
Sincerely,
William Brown
Sesion Software Engineer,
Identity and Access Management
SUSE Labs, Australia