[Date Prev][Date Next]
ITS#4535 back-config can allow break-ins
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
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
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/