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.
changed notes moved from Incoming to Software Enhancements
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 ------------------------------------------
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/
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.
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/
changed state Open to Feedback
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.
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/
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/ > >
Hello I believe this has been fixed. This ITS should be closed, IMO. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
changed state Feedback to Closed
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/
changed state Closed to Test
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 -----------------------------------
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
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/
changed notes changed state Test to Release
changed notes changed state Release to Closed
request for dITStructureRule implementation added to HEAD/RE24