OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Contrib/2914
Full headers

From: dsbroa0@aol.com
Subject: ACLs not quite followed when a PreBind plugin is involved
Compose comment
Download message
State:
0 replies:
4 followups: 1 2 3 4

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 9 Jan 2004 16:18:06 GMT
From: dsbroa0@aol.com
To: openldap-its@OpenLDAP.org
Subject: ACLs not quite followed when a PreBind plugin is involved
Full_Name: Darin Broady
Version: 2.2.4
OS: Irix 6.5.19m & Solaris 8
URL: ftp://ftp.openldap.org/incoming/DarinBroady-040109.patch
Submission from: (NULL) (192.146.101.11)


I have written a PreBind plugin that will allow us to use native Solaris LDAP
pam_ldap with our OpenLDAP server.  Everything was going well until I put in an
ACL that denied access to the server through the following:

access to dn.exact="cn=testing,o=dept,c=us" attrs=userPassword
     by * none

With my PreBind plugin disabled (ie. not loaded into the executable), I found
that this ACL worked as I expected.  However, with my PreBind plugin included, I
found that this ACL was not being adhered to.  Knowing that this was a access
problem, I looked through the SLAPI API to find out if there was a function that
I could use to test AUTH access to the userPassword attribute.  I found the
slapi_access_allowed function, but it only gives the ability to look at compare,
search, read,& write access.  I could not find a function in the SLAPI API
that
allows a plugin to check for AUTH access, which means that a PreBind plugin can
inadvertently subvert the ACLs.

I have a small patch can a fix it.  What it does is make an AUTH-test call to
access_allowed() on the userPassword attribute of the DN binding just before the
PRE_BIND plugins are called.  This should make it so that all PRE_BIND plugins
can not subvert the ACLs, at least for the userPassword attribute.  I have
tested the patch and it works great for us.


Followup 1

Download message
To: openldap-its@OpenLDAP.org
Subject: (ITS#2914)
From: dbroady@lexmark.com
Date: Fri, 9 Jan 2004 11:30:37 -0500
This is a multipart message in MIME format.
--=_alternative 005AB1D685256E16_=
Content-Type: text/plain; charset="us-ascii"

I put the wrong email address in the document.  It should be 
dbroady1@aol.com.  An alternative is   dbroady@lexmark.com

Darin Broady
--=_alternative 005AB1D685256E16_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">I put the wrong email address in
the document. &nbsp;It should be &nbsp; dbroady1@aol.com. &nbsp;An
alternative is &nbsp; dbroady@lexmark.com</font>
<br>
<br><font size=2 face="sans-serif">Darin Broady</font>
--=_alternative 005AB1D685256E16_=--



Followup 2

Download message
Date: Sat, 10 Jan 2004 11:37:07 -0800
To: dsbroa0@aol.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: ACLs not quite followed when a PreBind plugin is involved
  (ITS#2914)
Cc: openldap-its@OpenLDAP.org
At 08:18 AM 1/9/2004, dsbroa0@aol.com wrote:
>Full_Name: Darin Broady
>Version: 2.2.4
>OS: Irix 6.5.19m & Solaris 8
>URL: ftp://ftp.openldap.org/incoming/DarinBroady-040109.patch
>Submission from: (NULL) (192.146.101.11)
>
>
>I have written a PreBind plugin that will allow us to use native Solaris
LDAP
>pam_ldap with our OpenLDAP server.  Everything was going well until I put in
an
>ACL that denied access to the server through the following:
>
>access to dn.exact="cn=testing,o=dept,c=us" attrs=userPassword
>     by * none
>
>With my PreBind plugin disabled (ie. not loaded into the executable), I
found
>that this ACL worked as I expected.  However, with my PreBind plugin
included, I
>found that this ACL was not being adhered to.  Knowing that this was a
access
>problem, I looked through the SLAPI API to find out if there was a function
that
>I could use to test AUTH access to the userPassword attribute.  I found the
>slapi_access_allowed function, but it only gives the ability to look at
compare,
>search, read,& write access.

As SLAPI follows the Netscape access model, you just call slapi_access_allowed()
for compare.  (Maybe slapi_access_allowed() could be modified to map compare
to auth when called from a bind operation, but not knowing SLAPI internals, I'll
leave that to someone else to consider.)

>I could not find a function in the SLAPI API that
>allows a plugin to check for AUTH access, which means that a PreBind plugin
can
>inadvertently subvert the ACLs.
>
>I have a small patch can a fix it.  What it does is make an AUTH-test call
to
>access_allowed() on the userPassword attribute of the DN binding just before
the
>PRE_BIND plugins are called.

This is inappropriate.  slapd(8) shouldn't do much before a pre-operation
plugin.  (It's called pre- because it comes before slapd(8) does it work.)

Also, I note, the assumption that the password is held in userPassword is
flawed.

>This should make it so that all PRE_BIND plugins
>can not subvert the ACLs, at least for the userPassword attribute.  I have
>tested the patch and it works great for us.



Followup 3

Download message
Subject: (ITS#2914)
To: openldap-its@OpenLDAP.org
Cc: Kurt@OpenLDAP.org
From: dbroady@lexmark.com
Date: Wed, 14 Jan 2004 09:50:39 -0500
Kurt,

Thanks for your response.  One question:  When isn't the password for a
user not in some way stored in the userPassword attribute?

Also, if changing the slap_access_allowed() function is appropriate, then
here is a patch that would do what we need.  Let me know what you think of
this patch.

One final thing.  In my original posting of the problem, I entered the
wrong email address.  Would you please change it to   dbroady1@aol.com
instead of  dsbroa0@aol.com?  Thanks.


--- slapi_utils.c.orig  Wed Jan 14 09:39:25 2004
+++ slapi_utils.c Wed Jan 14 09:47:09 2004
@@ -3256,9 +3256,16 @@
            return ret;
      }

+     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
+           return LDAP_PARAM_ERROR;
+     }
+
      switch ( access & SLAPI_ACL_ALL ) {
      case SLAPI_ACL_COMPARE:
-           slap_access = ACL_COMPARE;
+           if (op && op->o_tag == LDAP_REQ_BIND)
+                 slap_access = ACL_AUTH | ACL_COMPARE;
+           else
+                 slap_access = ACL_COMPARE;
            break;
      case SLAPI_ACL_SEARCH:
            slap_access = ACL_SEARCH;
@@ -3282,10 +3289,6 @@
      }

      if ( slapi_pblock_get( pb, SLAPI_CONNECTION, (void *)&conn ) != 0 ) {
-           return LDAP_PARAM_ERROR;
-     }
-
-     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
            return LDAP_PARAM_ERROR;
      }



Darin Broady
dbroady@lexmark.com
Lexmark International, Inc.




Followup 4

Download message
Date: Wed, 14 Jan 2004 23:24:47 -0800
To: dbroady@lexmark.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: (ITS#2914)
Cc: openldap-its@OpenLDAP.org
At 07:18 AM 1/14/2004, dbroady@lexmark.com wrote:
>Kurt,
>
>Thanks for your response.  One question:  When isn't the password for a
>user not in some way stored in the userPassword attribute?

A backend could, for instance, implement the authPassword, the
unicodePwd, or other other password attribute.  Or the backend
could use an external password store.

>Also, if changing the slap_access_allowed() function is appropriate, then
>here is a patch that would do what we need.  Let me know what you think of
>this patch.

This patch seems more suitable.  However, I'll defer any action
regarding it to a committer with more experience with SLAPI.

>One final thing.  In my original posting of the problem, I entered the
>wrong email address.  Would you please change it to   dbroady1@aol.com
>instead of  dsbroa0@aol.com?  Thanks.
>
>
>--- slapi_utils.c.orig  Wed Jan 14 09:39:25 2004
>+++ slapi_utils.c Wed Jan 14 09:47:09 2004
>@@ -3256,9 +3256,16 @@
>            return ret;
>      }
>
>+     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
>+           return LDAP_PARAM_ERROR;
>+     }
>+
>      switch ( access & SLAPI_ACL_ALL ) {
>      case SLAPI_ACL_COMPARE:
>-           slap_access = ACL_COMPARE;
>+           if (op && op->o_tag == LDAP_REQ_BIND)
>+                 slap_access = ACL_AUTH | ACL_COMPARE;
>+           else
>+                 slap_access = ACL_COMPARE;
>            break;
>      case SLAPI_ACL_SEARCH:
>            slap_access = ACL_SEARCH;
>@@ -3282,10 +3289,6 @@
>      }
>
>      if ( slapi_pblock_get( pb, SLAPI_CONNECTION, (void *)&conn ) != 0
) {
>-           return LDAP_PARAM_ERROR;
>-     }
>-
>-     if ( slapi_pblock_get( pb, SLAPI_OPERATION, (void *)&op ) != 0 ) {
>            return LDAP_PARAM_ERROR;
>      }
>
>
>
>Darin Broady
>dbroady@lexmark.com
>Lexmark International, Inc.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org