Issue 4556 - ACLs related to the content of *new* entries
Summary: ACLs related to the content of *new* entries
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-18 19:28 UTC by andreas@canonical.com
Modified: 2014-08-01 21:04 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description andreas@canonical.com 2006-05-18 19:28:35 UTC
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.

Comment 1 ando@openldap.org 2006-05-18 20:51:11 UTC
changed notes
moved from Incoming to Software Enhancements
Comment 2 ando@openldap.org 2006-05-18 21:01:05 UTC
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
------------------------------------------

Comment 3 Howard Chu 2006-05-19 21:54:35 UTC
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/

Comment 4 andreas@canonical.com 2006-05-22 17:10:44 UTC
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.

Comment 5 Howard Chu 2006-05-29 01:07:39 UTC
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/

Comment 6 Howard Chu 2006-05-29 01:07:48 UTC
changed state Open to Feedback
Comment 7 andreas@canonical.com 2006-06-01 17:40:06 UTC
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.

Comment 8 Howard Chu 2007-02-07 23:22:10 UTC
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/

Comment 9 Kurt Zeilenga 2007-02-08 04:27:11 UTC
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/
>
>

Comment 10 manu@openldap.org 2008-10-28 15:26:13 UTC
Hello

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

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

Comment 11 ando@openldap.org 2008-10-28 16:30:42 UTC
changed state Feedback to Closed
Comment 12 Howard Chu 2008-10-28 18:36:01 UTC
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/

Comment 13 ando@openldap.org 2008-10-28 19:08:07 UTC
changed state Closed to Test
Comment 14 ando@openldap.org 2008-10-28 19:09:17 UTC
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
-----------------------------------

Comment 15 manu@openldap.org 2008-10-28 20:00:13 UTC
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

Comment 16 Howard Chu 2008-11-11 13:59:21 UTC
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/

Comment 17 Howard Chu 2008-11-24 07:02:32 UTC
changed notes
changed state Test to Release
Comment 18 Quanah Gibson-Mount 2008-11-24 17:08:50 UTC
changed notes
changed state Release to Closed
Comment 19 OpenLDAP project 2014-08-01 21:04:52 UTC
request for dITStructureRule implementation
added to HEAD/RE24