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