On Fri, 6 Oct 2000, Kelli Wolfe wrote: > After much caffeine, I have some answers. Red Hat 7.0 > changed the pam.d config files to use pam_unix rather > than pam_pwdb, which I had been using. The pam_unix > module is making a system call to get a user's password. > This system call is getting the LDAP passwords via > nss_ldap. So, even though the pam_ldap check fails, the > pam_unix succeeds because the encrypted password passes > the pam_unix test. > So, to resolve this problem, I've gone back to using > pam_pwdb, as it appears to look at files directly rather > than making system calls. It's somewhat worrying that nss_ldap is returning the user's password as part of the passwd struct. This suggests to me that there is at least a possible insecurity with nss_ldap: what happens if a non-privileged user calls getpwnam() for some other user's account (or root's!) that's stored in LDAP? Perhaps the authors of nss_ldap had a reason for allowing the password to be returned, but I can't imagine what that would be. The other side of this is that, if the password *is* being returned, there are probably configuration issues on your LDAP server. I'm taking a stab in the dark here, but I have my doubts that nss_ldap is binding to the LDAP server as a privileged user, either; which means that even if nss_ldap itself doesn't have any security bugs, other people could probably bind to the LDAP server directly and get access to user passwords. I think I'll do some digging into nss_ldap and pam_ldap soon, so that I know exactly what they allow, and what the expect... since we're planning on migrating to nss_ldap soon, I'd definitely like to know what we're getting into. Steve Langasek postmodern programmer
