[Pkg-openldap-devel] Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid

[Russ Allbery]

Howard Chu <hyc at symas.com> writes:

> This whole line of reasoning appears to be based on the assumption that
> OpenLDAP's ldap.conf and pam/nss_ldap's ldap.conf are equivalent, which
> is false.

Well, no, my line of reasoning is not based on this.  My line of reasoning
is based on the fact that a user who doesn't understand the full list of
parameters that must be specified in their local configuration opens
themselves to a security vulnerability that would allow an attacker to
spoof NSS information by changing the trust parameters for their LDAP
configuration so that the system would trust an LDAP server under the
control of an attacker.  This attack is very similar to the sorts of
attacks that can be launched against NIS; avoiding it is one of the
reasons why Stanford, at the least, moved away from NIS and towards LDAP
for NSS information since remote LDAP servers can be authenticated.

> pam/nss_ldap use their own config file, which is not the OpenLDAP
> default config file. A properly configured pam/nss_ldap fully specifies
> all of the options that pam/nss needs. In this situation, the presence
> of other ldap.conf and ldaprc files is irrelevant, since they can only
> be used to supply defaults when the calling application does not specify
> particular arguments. E.g., the URI in <openldap>/ldap.conf will only be
> used by libldap if the calling API doesn't specify a URI.

So your suggestion is that nss-ldap should verify that every possible
parameter with security sensitivity (definitely including, in this case,
the configuration of trusted certificate authorities) is set explicitly in
its configuration and, if not, abort?  That's similar, although somewhat
more complex, than the workaround that I suggested.

> Apps that intend to use libldap and intend to be installed setuid have
> the responsibility to insure that they are properly and adequately
> configured, such that arbitrary defaults outside the app's awareness are
> never used. That's just common sense.

Libraries should not attempt to open configuration files in the current
working directory.  That's just common sense.

Since, unfortunately, we live in a world that doesn't operate entirely by
the dictates of common sense for a variety of historic and hard-to-resolve
reasons, I'm more interested in how to fix the problem going forward so
that we aren't creating a situation where users can easily open a security
vulnerability by accident than arguing about our personal conceptions of
common sense.  As I'm sure you'd agree, being able to override the
system's concept of trusted certificate authorities pretty much defeats
the entire purpose of using TLS to authenticate a remote LDAP server.

So, there's a couple of options that the NSS module should verify are set,
obviously (the URI and the two TLS certificate authority paths).  Probably
BASE and TLS_REQCERT as well.  Now, though, I'm not sure what the security
implications are of not setting several other ones.  From the
descriptions, I can't immediately rule out possible interference with the
system security policy via TLS_CALCHECK, TLS_CIPHER_SUITE, SASL_SECPROPS,
SASL_MECH, SASL_REALM, SASL_AUTHCID, SASL_AUTHZID, DEREF, and REFERRALS,
although for the most part I'd expect fiddling with them to fail.

That's a lot to verify is set, some of which many users will not *want* to
set.  Can you provide more information about exactly what parameters the
NSS module needs to provide to ensure that none of the information in a
local ldaprc file will be used?  I'm not sure that I can picture what the
code should look like to ensure this.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>