Re: (ITS#4556) ACLs related to the content of *new* entries

[ahasenack@terra.com.br]

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.