Howard Chu <[EMAIL PROTECTED]> 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. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
