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.