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

Logged in as guest

Viewing Software Enhancements/4556
Full headers

From: ahasenack@terra.com.br
Subject: ACLs related to the content of *new* entries
Compose comment
Download message
State:
0 replies:
12 followups: 1 2 3 4 5 6 7 8 9 10 11 12

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 18 May 2006 19:28:35 GMT
From: ahasenack@terra.com.br
To: openldap-its@OpenLDAP.org
Subject: ACLs related to the content of *new* entries
Full_Name: Andreas Hasenack
Version: 2.3.23
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (200.103.133.238)


I think this is an enhancement request and not a bug, because as far as I can
see the behaviour I'm about to describe matches the documentation.

I would like to be able to prevent the creation of certain *new* entries.
Currently, acls only allow me to filter this via "attrs=children" and
"attrs=entry" (and RDN), with no regards to content.

Thus, in this sample scenario:
access to dn.sub="ou=dns,@SUFFIX@"
	attrs=children,entry,@dNSZone
	by group.exact="cn=DNS Admins,ou=System Groups,@SUFFIX@" write
        by * read

members of the "DNS Admins" group are able to create any entry at all, with any
objectClass, under ou=dns. But after the entry is created, they can only touch
the attributes of the dNSZone object class as expected.

I would like for these members to not be able to create entries under ou=dns
other than those with the dNSZone OC and its attributes. This would minimize
risks in setups where, for example, nss_ldap was wrongly configured to do
subtree searches starting at @SUFFIX@. This would be a security issue, because
the DNS Admins could create a posixAccount entry under ou=dns and give anyone
they want root access (uidNumber 0).

Having the ability to prevent the creation of specific entries would help
prevent such scenarios.


Followup 1

Download message
Subject: Re: (ITS#4556) ACLs related to the content of *new* entries
From: Pierangelo Masarati <ando@sys-net.it>
To: ahasenack@terra.com.br
Cc: openldap-its@OpenLDAP.org
Date: Thu, 18 May 2006 23:01:05 +0200
On Thu, 2006-05-18 at 19:29 +0000, ahasenack@terra.com.br wrote:

> I think this is an enhancement request and not a bug, because as far as I
can
> see the behaviour I'm about to describe matches the documentation.
> 
> I would like to be able to prevent the creation of certain *new* entries.
> Currently, acls only allow me to filter this via "attrs=children" and
> "attrs=entry" (and RDN), with no regards to content.
> 
> Thus, in this sample scenario:
> access to dn.sub="ou=dns,@SUFFIX@"
> 	attrs=children,entry,@dNSZone
> 	by group.exact="cn=DNS Admins,ou=System Groups,@SUFFIX@" write
>         by * read
> 
> members of the "DNS Admins" group are able to create any entry at all, with
any
> objectClass, under ou=dns. But after the entry is created, they can only
touch
> the attributes of the dNSZone object class as expected.
> 
> I would like for these members to not be able to create entries under
ou=dns
> other than those with the dNSZone OC and its attributes. This would
minimize
> risks in setups where, for example, nss_ldap was wrongly configured to do
> subtree searches starting at @SUFFIX@. This would be a security issue,
because
> the DNS Admins could create a posixAccount entry under ou=dns and give
anyone
> they want root access (uidNumber 0).
> 
> Having the ability to prevent the creation of specific entries would help
> prevent such scenarios.

I think the reason ACLs don't muck with the contents of an entry being
added is that ACLs apply to entries in a naming context, while an entry
being added does not belong to a naming context until it's added (catch
22?).  What you need is something like DIT structure rules (see draft-
ietf-ldapbis-models for details), which AFAIK is not implemented in
OpenLDAP yet.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution
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
------------------------------------------



Followup 2

Download message
Date: Fri, 19 May 2006 14:54:35 -0700
From: Howard Chu <hyc@symas.com>
To: ahasenack@terra.com.br
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#4556) ACLs related to the content of *new* entries
ahasenack@terra.com.br wrote:
> Full_Name: Andreas Hasenack
> Version: 2.3.23
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (200.103.133.238)
>
>
> I think this is an enhancement request and not a bug, because as far as I
can
> see the behaviour I'm about to describe matches the documentation.
>
> I would like to be able to prevent the creation of certain *new* entries.
> Currently, acls only allow me to filter this via "attrs=children" and
> "attrs=entry" (and RDN), with no regards to content.
>
> Thus, in this sample scenario:
> access to dn.sub="ou=dns,@SUFFIX@"
> 	attrs=children,entry,@dNSZone
> 	by group.exact="cn=DNS Admins,ou=System Groups,@SUFFIX@" write
>         by * read
>
> members of the "DNS Admins" group are able to create any entry at all, with
any
> objectClass, under ou=dns. But after the entry is created, they can only
touch
> the attributes of the dNSZone object class as expected.
>
> I would like for these members to not be able to create entries under
ou=dns
> other than those with the dNSZone OC and its attributes. This would
minimize
> risks in setups where, for example, nss_ldap was wrongly configured to do
> subtree searches starting at @SUFFIX@. This would be a security issue,
because
> the DNS Admins could create a posixAccount entry under ou=dns and give
anyone
> they want root access (uidNumber 0).
>
> Having the ability to prevent the creation of specific entries would help
> prevent such scenarios.

The scenario you describe is mitigated though, because no users can read 
any attributes besides those that are in the dnsZone objectclass.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/



Followup 3

Download message
Date: Mon, 22 May 2006 14:10:44 -0300
From: Andreas Hasenack <ahasenack@terra.com.br>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#4556) ACLs related to the content of *new* entries
On Fri, May 19, 2006 at 09:55:22PM +0000, hyc@symas.com wrote:
> > I would like for these members to not be able to create entries under
ou=dns
> > other than those with the dNSZone OC and its attributes. This would
minimize
> > risks in setups where, for example, nss_ldap was wrongly configured to
do
> > subtree searches starting at @SUFFIX@. This would be a security issue,
because
> > the DNS Admins could create a posixAccount entry under ou=dns and give
anyone
> > they want root access (uidNumber 0).
> >
> > Having the ability to prevent the creation of specific entries would
help
> > prevent such scenarios.
> 
> The scenario you describe is mitigated though, because no users can read 
> any attributes besides those that are in the dnsZone objectclass.

That depends on the rest of the acls, no? And at the least the DNS Admins could
become root. Of course there could be other ways for them to get root already,
being the master of DNS. DNS was just an example. The idea is to prevent
configuration accidents.

Anyway, it's not too difficult to fall into this trap when granting (groups of)
users the right to create new entries. I have no idea how common this scenario
is, I just came accross it while trying to delegate some administrative tasks
to others.



Followup 4

Download message
Date: Sun, 28 May 2006 18:07:39 -0700
From: Howard Chu <hyc@symas.com>
To: ahasenack@terra.com.br
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#4556) ACLs related to the content of *new* entries
ahasenack@terra.com.br wrote:
> On Fri, May 19, 2006 at 09:55:22PM +0000, hyc@symas.com wrote:
>   
>> The scenario you describe is mitigated though, because no users can
read 
>> any attributes besides those that are in the dnsZone objectclass.
>>     
>
> That depends on the rest of the acls, no? And at the least the DNS Admins
could
> become root. Of course there could be other ways for them to get root
already,
> being the master of DNS. DNS was just an example. The idea is to prevent
> configuration accidents.
>   

The ACL clause you provided was quite complete:

access to dn.sub="ou=dns,@SUFFIX@"
	attrs=children,entry,@dNSZone
	by group.exact="cn=DNS Admins,ou=System Groups,@SUFFIX@" write
        by * read


The only way for anybody to be able to read anything besides dNSZone 
attributes under this subtree is if you explicitly add another ACL 
clause to allow that.  If you're only expecting to create dNSZone 
objects under this subtree, then you have no reason to write additional 
ACL clauses for this subtree. I.e., you can only create a security hole 
here if you really want to, and if you really want to, that's your decision.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/



Followup 5

Download message
Date: Thu, 1 Jun 2006 14:40:06 -0300
From: ahasenack@terra.com.br
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#4556) ACLs related to the content of *new* entries
On Mon, May 29, 2006 at 01:07:48AM +0000, hyc@symas.com wrote:
> ahasenack@terra.com.br wrote:
> > On Fri, May 19, 2006 at 09:55:22PM +0000, hyc@symas.com wrote:
> >   
> >> The scenario you describe is mitigated though, because no users
can read 
> >> any attributes besides those that are in the dnsZone objectclass.
> >>     
> >
> > That depends on the rest of the acls, no? And at the least the DNS
Admins could
> > become root. Of course there could be other ways for them to get root
already,
> > being the master of DNS. DNS was just an example. The idea is to
prevent
> > configuration accidents.
> >   
> 
> The ACL clause you provided was quite complete:
> 
> access to dn.sub="ou=dns,@SUFFIX@"
> 	attrs=children,entry,@dNSZone
> 	by group.exact="cn=DNS Admins,ou=System Groups,@SUFFIX@" write
>         by * read
> 
> 
> The only way for anybody to be able to read anything besides dNSZone 
> attributes under this subtree is if you explicitly add another ACL 
> clause to allow that.  If you're only expecting to create dNSZone 
> objects under this subtree, then you have no reason to write additional 
> ACL clauses for this subtree. I.e., you can only create a security hole 
> here if you really want to, and if you really want to, that's your
decision.

That's not so far fetched, considering that most (all?) examples about ACLs in
the available documentation *end* with "access to * by * read" after having
secured access to several attributes. And these attributes remain secured, but
the scenario above is not taken into account.



Followup 6

Download message
Date: Wed, 07 Feb 2007 15:22:10 -0800
From: Howard Chu <hyc@symas.com>
To: openldap-its@openldap.org
Subject: ITS#4556 ditStructureRules
I've often thought about adding support here, but it looks like an 
all-or-nothing proposition. I.e., when you have a server that uses 
ditStructureRules, you must actually define a full set of rules otherwise you 
cannot add any user entries to the directory at all. This would be a pretty 
drastic change for people accustomed to the current behavior, where you can 
put any entry you like anywhere you like. Beginners have a hard enough time 
just getting their first two entries into the directory; requiring the use of 
ditStructureRules would seem to just make a bad situation worse.

Possibly we could make it a configurable option - enable them with a 
per-database setting, defaulting to off to preserve the current behavior. 
Fully aligning with X.500 practices would have to wait for a new generation 
of server. E.g., we currently support the use of subdatabases using 
subordinate/glue. These provide some of the notion of X.500 Administrative 
Areas, except their definitions reside in the cn=config tree, not as 
subentries of the main DIT. Providing full subentry-based administration 
would be a major change in how the server is operated and how the DIT is 
administered. Something for OpenLDAP 3.0.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   Chief Architect, OpenLDAP     http://www.openldap.org/project/



Followup 7

Download message
Cc: openldap-its@OpenLDAP.org
From: Kurt Zeilenga <kurt@OpenLDAP.org>
Subject: Re: ITS#4556 ditStructureRules
Date: Thu, 8 Feb 2007 04:27:11 +0000
To: hyc@symas.com
On Feb 7, 2007, at 11:22 PM, hyc@symas.com wrote:

> I've often thought about adding support here, but it looks like an
> all-or-nothing proposition. I.e., when you have a server that uses
> ditStructureRules, you must actually define a full set of rules  
> otherwise you
> cannot add any user entries to the directory at all. This would be  
> a pretty
> drastic change for people accustomed to the current behavior, where  
> you can
> put any entry you like anywhere you like. Beginners have a hard  
> enough time
> just getting their first two entries into the directory; requiring  
> the use of
> ditStructureRules would seem to just make a bad situation worse.

It may be possible to do something similar to what was done for
ditContentRules, which are also all or none in X.500 (no rules defined
means no use of aux objectcleasses in X.500).   In OpenLDAP, no rules
means any use of auxiliary classes is okay.  But if you add a rule, any
rule, then these defined rules must be followed.

-- Kurt

>
> Possibly we could make it a configurable option - enable them with a
> per-database setting, defaulting to off to preserve the current  
> behavior.
> Fully aligning with X.500 practices would have to wait for a new  
> generation
> of server. E.g., we currently support the use of subdatabases using
> subordinate/glue. These provide some of the notion of X.500  
> Administrative
> Areas, except their definitions reside in the cn=config tree, not as
> subentries of the main DIT. Providing full subentry-based  
> administration
> would be a major change in how the server is operated and how the  
> DIT is
> administered. Something for OpenLDAP 3.0.
> -- 
>    -- Howard Chu
>    Chief Architect, Symas Corp.  http://www.symas.com
>    Director, Highland Sun        http://highlandsun.com/hyc
>    Chief Architect, OpenLDAP     http://www.openldap.org/project/
>
>



Followup 8

Download message
To: openldap-its@openldap.org
Subject: ACLs related to the content of *new* entries (ITS#4556)
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Tue, 28 Oct 2008 17:26:13 +0200
Hello

I believe this has been fixed. This ITS should be closed, IMO.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org



Followup 9

Download message
Date: Tue, 28 Oct 2008 11:36:01 -0700
From: Howard Chu <hyc@symas.com>
To: manu@netbsd.org
CC: openldap-its@openldap.org
Subject: Re: ACLs related to the content of *new* entries (ITS#4556)
manu@netbsd.org wrote:
> Hello
>
> I believe this has been fixed. This ITS should be closed, IMO.
>
Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file. ITS's 
that involve code changes generally don't get closed until the change gets 
released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g. 
patches to something that only existed in HEAD...)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 10

Download message
Date: Tue, 28 Oct 2008 20:09:17 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: hyc@symas.com
CC: openldap-its@openldap.org
Subject: Re: ACLs related to the content of *new* entries (ITS#4556)
hyc@symas.com wrote:
> manu@netbsd.org wrote:
>> Hello
>>
>> I believe this has been fixed. This ITS should be closed, IMO.
>>
> Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file.
ITS's 
> that involve code changes generally don't get closed until the change gets 
> released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g. 
> patches to something that only existed in HEAD...)

Right.  I thought it was released, though. It was committed well before 
2.4.12 was released.  Moved to "test".

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Followup 11

Download message
To: hyc@symas.com (Howard Chu)
Cc: openldap-its@openldap.org
Subject: Re: ACLs related to the content of *new* entries (ITS#4556)
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Tue, 28 Oct 2008 22:00:13 +0200
Howard Chu <hyc@symas.com> wrote:

> Hm, fixed as of when? I don't see 4556 listed in the RE24 CHANGES file.
ITS's
> that involve code changes generally don't get closed until the change gets
> released. (Unless the ITS involves a Devel/HEAD-only piece of code, e.g.
> patches to something that only existed in HEAD...)

Given that rule, then it should remain open.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org



Followup 12

Download message
Date: Tue, 11 Nov 2008 05:59:21 -0800
From: Howard Chu <hyc@symas.com>
To: openldap-its@openldap.org
Subject: [Fwd: ITS#4556 ACLs for new entries]
For completeness' sake...

ACL checking for Added entries is available in RE24/HEAD. See the 
add_content_acl / olcAddContentAcl setting in slapd.conf/slapd.d. The default 
for most DBs is off, for backward compatibility. It is ON by default for 
cn=config.

-------- Original Message --------
Subject: ITS#4556 ACLs for new entries
Date: Fri, 21 Sep 2007 09:00:37 -0700
From: Howard Chu <hyc@symas.com>
To: OpenLDAP Devel <openldap-devel@openldap.org>

Revisiting this topic - DITStructureRules are not a solution to this problem.
E.g. in cn=config, now that you can grant write access to arbitrary users, it
becomes pretty critical to be able to prevent certain users from creating
certain types of objects. E.g., I may want to allow someone to be able to
create one type of child object under cn=config (e.g., databases) but not some
other type (e.g., modules). So at the very least we need to be able to use ACL
filters on new entries.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


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