On 2/24/22 1:06 AM, William Brown wrote:
>>
>>> • Shortcut InChain 'member' and 'memberof' into a use of
'memberof' attribute looks a very nice idea. Documentation should warn that
InChain 'member' relies on 'memberof' properly updated (risk of
enable/disable memberof plugin)
>>>
>> Yep - we already have that data, so we can rely on it and use it. I think we
should change memberOf to enabled by default TBH.
>
> Updating the design with your feedback I am facing a difficulty.
> There is a kind of agreement that a search like
'(member:1.2.840.113556.1.4.1941:=uid=foo,dc=com)'
> that computes all groups 'foo' is memberof, should shortcut the membership
computation to use 'memberof' value that is in 'foo' entry.
>
> My concern is related to access control. Let assume we have
>
> dn: G0
> member: G1
>
> dn: G1
> member: G2
>
> dn: G2
> member: foo
>
> dn: foo
> memberof: G0
> memberof: G1
> memberof: G2
>
> Then ACI definition, allows (to the inChain bound user) read/search access to
>
> • 'memberof' on 'foo'
> • 'member' on G2 and G0 but not on G1.
> InChain MR computation will retrieve G2 (because of access granted on G2.member),
then will not retrieve G1 (because of lack of rights to access to G1.member) and so not
retrieve G0. => returns 'G2'
>
> Shortcut InChain MR, retrieve G0, G1 and G2 (because of access granted to
foo.memberof). If it returns G0, G1, G2 it violates lack of access to G1.
> If it tests access of 'member' on G0, G1, G2. It may return G0 and G2
(because access is granted) but it violates the fact that G0 was hidden behind G1.
> So even if the 'member' are pre-computed, we still have to access (srch) each
of the member value to evaluate rights and also to create a graph of the membership to
detect "hidden" entries.
> In clear I am unsure of the benefit of the shortcut
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).
> any thoughts.
>
>
>
> best regards
> thierry
--
Sincerely,
William Brown
Sesion Software Engineer,
Identity and Access Management
SUSE Labs, Australia