ITS#4535 back-config can allow break-ins

[hyc@symas.com]

The first issue here was in regards to protection for the config backend when 
running the tests in the test suite. That was addressed mainly by using a 
randomly generated rootpw for cn=config in all of the tests. Also the default 
ACL for the config backend is explicitly set to "access to * by * none".

In terms of the potential attacks on a server through back-config - it's 
obvious to me that you have to treat access to back-config the same as you 
would treat SSH credentials for a root user on the machine. That was one of 
the main reasons I decided to make cn=config only usable by its rootdn in 
2.3. But since you really should be able to delegate authority, we added 
regular ACL support for 2.4.

So it still comes down to having sane ACLs configured.

Most of the attacks listed here require a user to have shell access to the 
machine, and write access to relevant filesystems. Frankly I think these 
attack scenarios are contrived - if you have untrusted users logging in to 
your system, you have other problems already.

re: a meta-config file - No. The design goal here is to remove all 
limitations that prevent totally remote administration of the server, not add 
new ones. Artificial restrictions, just like artificially restricting 2.3 to 
rootdn only, will only impair usability and eventually get removed.

re: lstat/fstat to prevent use of symlinks - No. There are too many valid 
uses for symlinks. What might make sense would be to fstat targets and check 
that they are owned by the current user and are not world-writable. We might 
also include root-owned directories that are world-writable with the sticky 
bit set.

re: Documentation - sure.

re: slaptools with -r/-u/-g - That's been discussed in ITS#4719. The 
consensus there seems (to me) to be that people with root access better know 
wth they're doing.

re: adding dangerous database configurations - this raises a question about 
the config DIT. It implies a need for individual containers for backends, 
databases, and modules, so that you can configure write access to their 
children attribute. Otherwise, at the moment, we have no way to give fine 
grained access as to who can create what entries. The other alternative is to 
make back-config's add handler check for wadd access to the objectclass 
attribute of new entries, which would be oddly inconsistent with regular 
backend behavior. I specifically omitted such containers in the original DIT 
because I assumed only a rootDN, and with the object types essentially coded 
into their RDNs, the containers were superfluous. I still consider such 
containers redundant, and would lean toward the objectclass ACL check, which 
we can also make value-dependent to control exactly what types of databases 
an administrator can add.

Assuming we have fine-grain control over what databases can be added, there 
should be no further consideration of whether to allow back-passwd, 
back-perl, or whatever. If an authorized admin wants to add them, let them.

Fine-grained restriction of modules is pretty much irrelevant - all we have 
to go on is a name, which need not bear any relation to the module's actual 
content. The best we can do here is check ownership, as with other 
path-related items.

re: Can one add "some-attribute:< file:///foobar" over the protocol to
   a back-ldif database to read file /foobar?  I don't think so, but...?
No. The URL is processed by the LDIF reader, which in this case is the client.

At this point we should probably split this ITS into a few different ones. 
The main point, vulnerability in the test suite, has already been addressed. 
The doc-related issues obviously should go to a Doc bug. That leaves path 
ownership/permission checking for one bug, and fine-grained control of Adds 
as a separate bug.

-- 
   -- 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/