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