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

Logged in as guest

Viewing Archive.Software Bugs/4654
Full headers

From: technosophos@gmail.com
Subject: slapacl behavior seems suspect
Compose comment
Download message
State:
0 replies:
2 followups: 1 2

Major security issue: yes  no

Notes:

Notification:


Date: Sun, 27 Aug 2006 04:30:13 GMT
From: technosophos@gmail.com
To: openldap-its@OpenLDAP.org
Subject: slapacl behavior seems suspect
Full_Name: M Butcher
Version: 2.3.27
OS: Linux (Ubuntu 6.06)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.34.42.242)


Problem: Running slapacl, attributes marked as 'auth' and '=x' are shown to be
readible.

I first noticed this on 2.3.25 and posted the message to the list. In the
meantime, 2.3.27 was released. At Pierangelo's request, I tested against
2.3.27.

Step-by-step account of what I did to test:
1. Built from 2.3.27 and installed
2. Deleted old database files (from 2.3.25)
4. Manually checked version on slapd, symlink on slapacl. Also checked to make
sure backend directory was empty.
5. Created minimal slapd and minimal testing ldif (see below)
6. Used 'slapadd -l testing.ldif' to add the LDIF
7. Ran test against cn -- read authorized on =x  (full output posted below)
8. Ran test against userPassword -- read authorized on auth (full output pasted
below)

7 and 8 seem to indicate incorrect behavior (or is there a reason slapacl would
give read access to auth/=x?)

Let me know if you need configure/make info, or if more logging would be
helpful. It seems quite easy for me to reproduce the bug consistently.

The LDIF (comments removed in original):
########
# BEGIN
dn: dc=example,dc=com
description: Example.Com, your trusted non-existent corporation.
dc: example
o: Example.Com
objectClass: top
objectClass: dcObject
objectClass: organization

dn: ou=Users,dc=example,dc=com
ou: Users
description: Example.Com Users
objectClass: organizationalUnit

dn: uid=matt,ou=Users,dc=example,dc=com
ou: Users
uid: matt
cn: Matt Butcher
sn: Butcher
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
userPassword: secret

dn: uid=barbara,ou=Users,dc=example,dc=com
ou: Users
uid: barbara
sn: Jensen
cn: Barbara Jensen
userPassword: secret
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
# END
########

SLAPD.CONF
########
# BEGIN

include   /etc/ldap/schema/core.schema
include   /etc/ldap/schema/cosine.schema
include   /etc/ldap/schema/inetorgperson.schema

pidfile   /usr/local/var/run/slapd.pid
argsfile  /usr/local/var/run/slapd.args
loglevel  none

modulepath      /usr/local/libexec/openldap
moduleload      back_hdb

access to attrs=userPassword
        by anonymous auth
        by self write
        by * none

access to attrs=cn
        by users =x
        by self write
        by * none

access to *
        by self write
        by users read
        by * none

database        hdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          secret
directory       /usr/local/var/openldap-data
index   objectClass     eq
index   cn      eq,sub,pres,approx
# END
########

RUNNING SLAPACL
# slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b
'uid=barbara,ou=Users,dc=example,dc=com' -d acl 'cn/read'

Backend ACL: access to attrs=userPassword
        by anonymous auth
        by self write
        by * none

Backend ACL: access to attrs=cn
        by users =x
        by self write
        by * none

Backend ACL: access to *
        by self write
        by users read
        by * none

authcDN: "uid=matt,ou=users,dc=example,dc=com"
=> access_allowed: read access to "" "cn" requested
=> access_allowed: backend default read access granted to
"uid=matt,ou=users,dc=example,dc=com"
read access to cn: ALLOWED

# slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b
'uid=barbara,ou=Users,dc=example,dc=com' -d acl 'userPassword/read'

Backend ACL: access to attrs=userPassword
        by anonymous auth
        by self write
        by * none

Backend ACL: access to attrs=cn
        by users =x
        by self write
        by * none

Backend ACL: access to *
        by self write
        by users read
        by * none

authcDN: "uid=matt,ou=users,dc=example,dc=com"
=> access_allowed: read access to "" "userPassword" requested
=> access_allowed: backend default read access granted to
"uid=matt,ou=users,dc=example,dc=com"
read access to userPassword: ALLOWED

Same thing woutout debugging (if this is what Pierangelo wants...):

 # slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b
'uid=barbara,ou=Users,dc=example,dc=com' 'cn/read'

authcDN: "uid=matt,ou=users,dc=example,dc=com"
read access to cn: ALLOWED

# slapacl -D 'uid=matt,ou=Users,dc=example,dc=com' -b
'uid=barbara,ou=Users,dc=example,dc=com' 'userPassword/read'

authcDN: "uid=matt,ou=users,dc=example,dc=com"
read access to userPassword: ALLOWED




Followup 1

Download message
Date: Sun, 27 Aug 2006 00:12:15 -0500
From: TechnoSophos <technosophos@gmail.com>
To: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: Re: (ITS#4654) slapacl behavior seems suspect
I should note that when using a client app (namely, ldapsearch), it is
the case that read access is not granted to cn and userPassword, so
the problem does not seem to be a security issue.

On 8/26/06, openldap-its@openldap.org <openldap-its@openldap.org> wrote:
>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System.  Your
> report has been assigned the tracking number ITS#4654.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers.  They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message.  Note that
> any mail sent to openldap-its@openldap.org with (ITS#4654)
> in the subject will automatically be attached to the issue report.
>
>         mailto:openldap-its@openldap.org?subject=(ITS#4654)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
>     http://www.OpenLDAP.org/its/index.cgi?findid=4654
>
> Please remember to retain your issue tracking number (ITS#4654)
> on any further messages you send to us regarding this report.  If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
>         http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved.
>
>



Followup 2

Download message
Date: Mon, 28 Aug 2006 13:31:43 +0200 (CEST)
Subject: Re: (ITS#4654) slapacl behavior seems suspect
From: "Pierangelo Masarati" <ando@sys-net.it>
To: technosophos@gmail.com
Cc: openldap-its@openldap.org
After closely looking at the code, when running slapacl global access
rules do not get appended to each database specific rules.  In fact, this
only happens when backend_startup() is called with NULL argument, while
slapacl calls it for each database passing the database's pointer as
argument.

As far as I can recall, this occurred because one of the backends, namely
the one resulting from selecting for the DN passed with the "-b" switch,
is already started up when control is passed to slapacl.

I've fixed this by appending global access rules also when
backend_startup() is called with a non-null argument; maybe a better fix
would be to move this inside backend_startup_one(), unless I'm overlooking
anything.

The fix can be extracted from the CVS by running

cvs diff -u servers/slapd/backend.c -r 1.366 -r 1.367

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------


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