Re: isn't pam_ldap inherently insecure?

["Prasad A. Chodavarapu" <chprasad@hotmail.com>]

Thanks a lot for the clarification, Stephen. I've now changed my ACLs
appropriately. I'm attaching the ACLs for comments. Although these ACLs
seem to be enough to use pam_ldap for authentication, i do see that pam
is attempting to read all attributes of the entry. The failure to read
them is not hurting its capability to authenticate but still, i'm
puzzled as to why it attempts that.


#firstly, we give everyone, read access to "entry" pseudo-attribute
access to attr=entry
       by dn="cn=ldapAdmin,dc=aalayance,dc=com" write
       by * read

#private but modifiable (by self) attributes
access to attr=userPassword
       by dn="cn=ldapAdmin,dc=aalayance,dc=com" write
       by self write
       by anonymous auth

#protected but read only attributes. Of these, a few like uid should
still be
#anonymously searchable for authentication agents like pam_ldap
access to
attr=dn,sn,givenname,ou,title,employeeType,manager,uidNumber,gidNumber,h
omeDirectory,loginShell,gecos,shadowLastChange,shadowMin,shadowMax,shado
wWarning,shadowInactive,shadowExpire,shadowFlag,description,owner,o
       by dn="cn=ldapAdmin,dc=aalayance,dc=com" write
       by users read
       by anonymous auth

access to attr=objectClass,uid,cn,uniqueMember,memberUid
       by dn="cn=ldapAdmin,dc=aalayance,dc=com" write
       by users read
       by anonymous search

#rest are protected and modifiable (by self) attributes
access to *
       by dn="cn=ldapAdmin,dc=aalayance,dc=com" write
       by self write
       by users read
       by anonymous auth


----- Original Message -----
From: "Stephan Siano" <stephan.siano@suse.de>
To: "Prasad A. Chodavarapu" <chprasad@hotmail.com>;
<openldap-software@OpenLDAP.org>
Sent: Wednesday, January 09, 2002 2:19 AM
Subject: Re: isn't pam_ldap inherently insecure?


> On Wednesday, 9. January 2002 06:13, Prasad A. Chodavarapu wrote:
> > pam_ldap seems to require 'read' access to the whole entry; i found
this
> > out thru openldap's debug trace. After successfully searching for an
> > 'uid' (along with any filters set, e.g. objectClass=posixAccount),
> > pam_ldap seems to attempt a 'read' of the entire 'entry' without
> > rebinding to the DN of the user being authenticated. It thus
requires
> > 'read' privileges on all user accounts (in violation of the 'shadow'
> > principles). There are two insecure ways out -
> >
> > a)grant read permissions on the entire user tree to 'anonymous'
users!
> > or
> > b)ask pam_ldap to bind as a special user who's granted 'read' on the
> > entire user tree. This is insecure as well as the special user's DN
and
> > password has to be stored in clear text in /etc/ldap.conf, a world
> > readable file (pam runs with the privileges of the user bring
> > autheticated). Thus, you can't even get security by obscurity.
> >
> > What's a good way out or am I missing something?
>
> I haven't looked into the pam_ldap-code (I would guess that's a
question to
> some other list...), but I rather doubt that there is a problem. If
you got
> the entry from the slap-logs it means that pam_ldap requires anonymous
read
> access to the pseudoattribute 'entry'. That is ideed the case, if you
can't
> anonymously read entry, you can't anonymously access anything in the
object,
> however access to the entry pseudoattribute gives you only access to
the
> object itself, but not to any of the attributes. I would guess to make
> pam_ldap work, you would at least need anonymous read access to the
> pseudoattribute entry and the attribute uid and auth access to the
attribute
> userPassword. You may also need some access to the ObjectClass
attribute, I'm
> not sure about this.
>
> You definetly should not need read access to the userPassword
attribute (and
> that's less or more what the shadow thing is about...)
>
> Yours
>
> Stephan Siano
>
> --
> Stephan Siano                           Mail:  Stephan.Siano@suse.de
> SuSE Linux Solutions AG                 Phone: 06196 50951 31
> Mergenthalerallee 45-47 Fax:   06196 409607
> D-65760 Eschborn
>