[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

At 08:55 AM 2/26/2005, Hallvard B Furuseth wrote:
>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.

I note that the server might not even implement the Search operation,
so saying same as "search" or same as "search filters" could have
some odd implications.


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

Please feel free to offer specific text for consideration.


>>>>> 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.

Ah, but the client could have used its modify rights to do:
        changetype: modify
        delete: foo
        foo: bar
        -
        add: foo
        foo: bar
        -

To see if that hidden <bar> exists.  Or:
        control: no-op
        changetype: modify
        add: foo
        foo: bar
        -

My point here is that "right to modify" often implies a right
to make assertions, at least certain kinds of assertions, as
these assertions are necessary to perform the operation.


>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.

The access control model may have "don't disclose on error"
provisions.

>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?

I generally presume there will be access checks in different
parts of the overall processing of the request, including
in finding the target object, performing the assertion, and
performing the "normal" processing.

>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.

Correct.  Or use no-op control as I demonstrated above.


>> 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


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