[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Filter to AND with uid=%s

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

Steve Langasek
postmodern programmer

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []