[Pkg-openldap-devel] r750 - in openldap/trunk-2.1: debian libraries/libldap

[Russ Allbery]

Quanah Gibson-Mount <quanah at stanford.edu> writes:
> Steve Langasek <vorlon at debian.org> wrote:

>> I don't accept this reasoning.  The penalty to an admin for configuring
>> their software "wrong" -- where "wrong" means "assuming that options
>> left as defaults will keep the default values" -- should not be a root
>> security hole.

> Huh?  As long as the admin has told nss/pam ldap to explicitly use an
> ldap configuration file, that is what it will use, regardless of what is
> in the user's .ldaprc file, i.e., the defaults will not be over ridden
> by whatever is in their local file.

Software needs to fail secure, not fail open.  A user configuration
mistake like that, which has no obvious security consequences, shouldn't
result in a potential security vulnerability, and this configuration is
not, so far as I can tell, under the control of the Debian package.

>> I agree that libnss-ldap and libpam-ldap should be using this
>> LDAPNOINIT flag, now that we know it exists.

I'm not sure they actually can.  It appears to be an environment variable,
which would then affect the entire process, which looks unacceptable to
me.  At first I'd thought it was some sort of option passed to the
initialization routine, but that doesn't appear to be the case.

>> Cc:ing the original bug report, so that Stephen can look into that.
>> But this should still be *in addition to* the suid check, not *instead
>> of* it, because there may be suid applications using libldap by other
>> means because they assume it's secure.

Agreed.

> Based on my discussions with Howard, I don't think your patch does what
> you think it does.

So, what does it do, then?  How doesn't it work?  What would work instead
given the above constraint?

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>