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

RE: SASL, slapd internal searches



> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> At 08:25 AM 3/8/2003, Igor Brezac wrote:

> >> I did not study your changes; however, I think you should ensure
> >> that authz code does have the necessary auth permissions, such
> >> that an administrator is given the possibility to control how
> >> the auth/authz process takes place, and to inhibit some forms of
> >> it by means of ACL.  I think this is the spirit of the auth
> >> permission level.

> >It is important that ACLs be applied to the resulting DN of
> the internal
> >search. However, saslauthz is more complicated than
> sasl-regex because
> >sasl-regex is setup by the administrator; on the other hand
> saslAuthz*
> >attribs are normally managed by users.  If a root-privileged
> operations
> >are allowed, saslAuthzTo can easily be abused.  I wonder if a special
> >saslAuthz acl can be implemented?

The docs already recommend that saslAuthzTo only be writable by privileged
users. The easiest thing to do is "access to attr=saslAuthzTo by * auth" and
only let the rootDN write it.
>
> The internal authentication/authorization searching, as with all
> other authentication/authorization access, should be done anonymously
> but require "auth" not "search"/"read".  This allows the administrator
> have complete control over which values in the directory are to be
> used for authentication/authorization purposes.

Yes. Where specific values are requested, such as slap_sasl_checkpass, AUTH
access is explicitly checked. This is not the issue though; the problem is
that a normal backend search is done in the first place, and this search
requires anonymous SEARCH access in order to locate any entry. Additionally,
when evaluating a search in a sasl-regexp map, test_filter() requires SEARCH
access to each of the attributes in the filter. Since these searches are
administrative, configured by the admin in the first place, I believe they
should always be unrestricted. Otherwise it requires you to set ACLs that
give anonymous SEARCH access to entries and various attributes.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support