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

Re: ACM Security Considerations



Another thing that could be addressed here would be "sort of holes in the
Access Model".

For example the observation that
having the compare right on an attribute "in the limit" allows you to
determine it's
value...which amounts to having read access to it.

Is this considered a serious hole ?  I think it at least deserves mention
in the draft.

Are there other examples like this ?

Rob.

"Kurt D. Zeilenga" wrote:

> I think this section needs additional flushing out.  Here
> are some comments in this area:
>
> I believe some discussion about what can happen if an attacker is able
> to add/modify/delete ldapACI and other ACM attributes (such
> as the mechanism) might have.  For example, if the attacker
> were able to change the mechanism, all access to all users
> might be denied.  If unauthorized access to ldapACI were gained,
> the user could grant or deny access for not only herself but
> other users.  Etc.
>
> Since the existing concern states ACI attributes are
> "security-sensitive information" but only states
> "unauthorized modification whenever it is stored or transmitted"
> should be safeguarded. I would suggest add someing about in the
> clear access.  That is, if the information is truely security-sensitive
> than allowing any access is an issue.  [many security experts believe
> that details of security policy and it's implemention should be
> safeguarded].  Implementations might consider requiring strong
> authentication and/or privacy and integrity safeguards before
> allowing access to ACIs.
>
> You might also note that implementation might want to provide
> out-of-directory restrictions upon what accesses in-directory
> can grant/deny.  [I believe this is already allowed by the
> spec via the "No mechanisms are defined in this document to
> control access to access control information."  That is,
> an implementation is free to return unwillingToPerform (or
> other suitable resultCode) if there is some administrative
> control which prohibit from performing the update operation.
> [I believe this MUST be allowed.  In some (GOV,MIL,B2B)
> environments, "dynamic" (in directory) access control
> information must be restricted by "static" (external to
> directory configuration) means.]
>
>         Kurt