Re: [ldapext] draft-zeilenga-ldap-assert-05 notes

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 12:18 PM 2/24/2005, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>>At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote:
>>>>draft-zeilenga-ldap-assert-05.txt says:
>>>>> 4.  Security Considerations
>>>>>
>>>>>   As with any general assertion mechanism, the mechanism can be used to
>>>>>   determine directory content.  Hence, this mechanism SHOULD be subject
>>>>>   to appropriate access controls.
>>>>
>>>>I suggest to add something like:
>>>>
>>>>    ... preferably the same access controls as search filters.
>>
>> (...)
>>> I rather not state a preference as part of a security considerations
>>> unless there is a good security related reason for that preference.
>>
>>The security reason I'm aware of is that I got it very wrong the
>>first time I thought of implementing access controls for this control.
>
> Wrong?  or just not the way you thought it should be for the
> particular access control you were using?

Different from how I thought it should work is wrong enough when I'm the
one who did it:-)  Which doesn't mean anyone else would do the same, of
course.

> Saying "SHOULD be subject to appropriate access controls" implies
> that the implementor should careful consider what is appropriate within
> the particular access model used in that implementation.  I find it
> difficult to suggest what might be appropriate in general as that
> requires, I think, making some assumptions about the access control
> model.

Me too, now that I've thought about it.  "Same as for filters" was too
broad for what I was trying to address; I should at least have said
filters in baseobject searches, since one could have different access
controls for baseobject searches and other searches.  So I can well
imagine there are other ways I haven't thought of.

Still, I do think there are pitfalls and it would be useful to flesh out
the issue somewhat.  See below.

>>>> The implementor might find the same access controls as for Compare
>>>> natural, but the server admin might e.g. not want substring matching to
>>>> be possible - and he could have written the Compare ACLs knowing that
>>>> Compare can't do substring matching.  Or one might mistakenly use the
>>>> same ACLs as for the "basic" operation being performed, e.g. Modify.
>>>
>>> It seems to be your statements depend greatly on what the
>>> access control model is...  I can certainly envision models
>>> where that would not be a mistake.
>>
>>Can you give an example?  Hypothetical or not.
>
> I think it would be reasonable to allow a user authorized to
> perform a modify to make that modify conditional.

I hope not, if you mean conditional on any part of the entry.  Then if I
have Modify access to attribute <foo> in an entry but attribute <bar> is
hidden from read/search/compare by access controls, I can subvert those
access controls by e.g. trying remove a non-existent value from <foo> or
modify it to contain the same value as before, conditional on a <bar>
filter.  noSuchAttribute or success reveal that the filter matches the
"hidden" value of <bar>.  assertionFailed reveals that it does not.

Come to think of it, that can work even without Modify access.  Getting
insufficientAccessRights instead of assertionFailed can reveal that the
assertion succeeded, unless the server implementor took care to check
all access controls before checking the assertion.  That may even be a
correct interpretation of the draft's literal wording.  Are access
checks part of "processing" the operation, which is only done if the
assertion succeeds?

With some caveats, the same seems to me to apply if <foo> and <bar> are
the same attribute.  If access is set so that one can write but not test
an attribute, there is presumably some reason for it.  Allowing people
to provide secret input to some questionnaire, maybe.  But in that case
one can in any case simulate an equality filter by attempting to add and
remove again the value to be tested.

> In a model where "search" rights includes "read" rights, I don't see
> in necessary to requires "search" rights.

Well, in that model, to require "same access controls as search filters"
would require "read" rights.

-- 
Hallvard

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext