Howard Chu <hyc@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.
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.