Howard Chu hyc@symas.com writes:
Have a look in _nss_ldap_init_config in nss_ldap/util.c (there's a similar function in pam_ldap.c)...
[...]
Thank you! This was extremely helpful to me. It looks like the only real issues from an NSS (and PAM) perspective are:
tls_checkpeer - this is a vulnerability, as the pam/nss default is to not set it and use the library default. Probably pam/nss should be patched to use an explicit setting here.
tls_cacertfile/cacertdir - generally one of these must be specified for TLS to work at all. If you omit these then yes some other trusted certs may get used. It may be legitimate to omit these settings if you have turned checkpeer off, but obviously that's an insecure configuration to begin with.
since everything else is either irrelevant, being set already, or requires ridiculously tortured logic to become an exploit.
I assume from the ldap.conf documentation that if tls_cacertfile is set, tls_cacertdir is irrelevant? Or are both explored for a root cert to validate the remote server?
I think that if both the NSS and PAM modules deal with those variables, that removes most of my concern. I'd still feel generally better with a safety net in the library for setuid processes on the principle of defense in depth and because safely using the LDAP library in such a situation requires thinking more about configuration initialization than I think some users may realize, but I'll freely admit that my concern at that point is theoretical.