Re: Posix group with /etc/ldap.conf read priv

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Tuesday, 15 June 2010 09:01:13 Daniel wrote:
> Buchan Milne wrote:
> > On Monday, 14 June 2010 17:03:29 Ariel wrote:
> >> I don't like having the /etc/ldap.conf world readable because then
> >> anyone who has shell access can see our general ldap login credentials
> >> (without which you cannot see anything in the ldap tree).  So I have
> >> added a posixgroup in ldap, added our shell users to it and did:
> >>
> >> chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
> >>
> >> But when logging in to the shell, users still get the "I have no name!"
> >>  problem because they cannot read the /etc/ldap.conf and cannot map
> >> their uid / guid numbers to names from the ldap tree.
> >>
> >> Advice?
> >
> > nss_ldap already caters to this, by the 'rootbinddn' option, and the
> > /etc/ldap.secret file. If rootbinddn is used, then process which are
> > running as root use this DN, and the password from the /etc/ldap.secret
> > file (which can thus be protected from non-root users).
> 
> The rootbinddn is just usefull/used in case of privileged (e.g. password
> reset by root) operations (which is normally done by root) therefore the
> file system permissions of /etc/ldap.secret can (should!) be protected.

No, this is not the only reason for the rootbindd option. In this case, I have 
no binddn/bindpw (I usually use SASL):

Without rootbinddn, getent passwd as root:
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 fd=34 ACCEPT from 
IP=127.0.0.1:58579 (IP=0.0.0.0:389)
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=0 BIND dn="" method=128
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=0 RESULT tag=97 err=0 text=
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SRCH 
base="dc=ranger,dc=dnsalias,dc=com" scope=2 deref=0 
filter="(objectClass=posixAccount)"
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SRCH attr=uid userPassword 
uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SEARCH RESULT tag=101 err=0 
nentries=32 text=
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 fd=34 closed (connection lost)


With rootbinddn, getent passwd as root:

Jun 15 11:02:01 tiger slapd[4884]: conn=3140 fd=35 ACCEPT from 
IP=127.0.0.1:37331 (IP=0.0.0.0:389)
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 BIND dn="uid=LDAP 
Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" method=128
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 BIND dn="uid=LDAP 
Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" mech=SIMPLE ssf=0
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 RESULT tag=97 err=0 text=
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SRCH 
base="dc=ranger,dc=dnsalias,dc=com" scope=2 deref=0 
filter="(objectClass=posixAccount)"
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SRCH attr=uid userPassword 
uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SEARCH RESULT tag=101 err=0 
nentries=32 text=
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 fd=35 closed (connection lost)


> rootbinddn and /etc/ldap.secret have no effect on standard nss
> operations invoked by unprivileged users.

Sure, but it *does* have an effect on any nss operations by a process running 
as root.

> > In order to make effective use of this, you probably need to run nscd (as
> > root, thus it is able to contact the LDAP server as rootbinddn).
> >
> > Of course, you need to consider:
> > 1)The fact that users who would have access to credentials already have
> > access to the information you are trying to protect
> > 2)The identity you use for nss_ldap should be least-privilege in any case
> 
> I've a question in regard to the exactly representation of
> "least-privilege" (hardening of slapd) to operate with nss_ldap. But
> first let me try to summarize my investigations:
> 
> The problem I see is that [nss|pam]_ldap's configuration file
> /etc/ldap.conf needs to be world readable to support a directory listing
> like for example "ls -al /home" wherein all the uidNumbers get resolved
> into names (uid/cn).

By design, it should be world readable. If you want credentials to be 
protected, use rootbinddn and /etc/ldap.secret, and e.g. nscd to ensure 
lookups end up being done by root.

> In my opinion there are two kind of approaches in regard to slapd's
> privilege configuration (ACLs) which both result in nearly the same
> behavior:
> 
> 1.) don't use a bindDn in /etc/ldap.conf and allow anonymous read in
> slapd (limited to posix account objectClass' attributes)
> 
> 2.) use a bindDn in /etc/ldap.conf which also requires a "bindPw". Thus
> /etc/ldap.conf needs to be world readable this approach also results in
> some kind of "quasi-anonymous" access (in case a logged in user uses the
> bindDn/bindPw for his own experiments ;-))

3)Use rootbinddn and /etc/ldap.secret with nscd or similar, with or without 
binddn/bindpw.

> To limit the possible side-effects (information disclosure) slapd's ACL
> settings need to be very restrictive but there are not many
> possibilities to further restrict queries without "damaging" the
> standard nss behavior (e.g. resolving uidNumber and so on).
> 
> Even in case the ACLs are strictly limited to deliver only
> posixAccount/shadowAccount relevant attributes, in most commonly ldap
> driven environments the nss|pam_ldap deployments disclose more security
> relevant information than the previous (non-ldap) /etc/passwd
> /etc/shadow approach:

Only if you use ldap for shadow ... if you don't, you will disclose less.

> Regardless whether approach 1.) or 2.) (which you are forced to in case
> your directory does not support anonymous binds - e.g. MS AD

AD supports anonymous binds, but it is disabled by default, but then again SSL 
isn't available by default ...

> ) is
> deployed a simple ldapsearch (anonymous or by use of bindDn/bindPw)
> delivers the /etc/passwd similar content to satisfy/achieve the unix
> system's standard nss behavior:
> "user:uidNumber:gidNumer:gecos: ...."
> 
> That's fine, but how about ldapsearch "+" (querying for operational
> attributes)?

They are subject to ACLs, just like any other attributes.

> By querying the operational attributes any interested user could get for
> example "helpful" additional information in comparison to /etc/passwd to
> narrow valuable attacks:
> - createTimestamp could be a good indicator for "old" and might be
> higher privileged users?
> - modifyTimestamp could be used to identify users who have not changed
> their passwords for years...
> - and many more ideas regarding the other operational attributes

So, don't allow access to these attributes by your proxy DN or anonymous, in 
either of the 2 cases above.

> Summary: In my opinion the only (theoretical?) chance left to further
> "harden" nss|pam_ldap deployments (by further restricting slapd's ACLs)
> is to suppress delivery of some operational attributes (for the
> nss|pam_ldap's proxy-user bindDn!) to a minimum.
> 
> I've (just for fun) already experimented with this. And all I can say
> nss|pam_ldap and slapd are still working fine but - and now let me come
> to the question:
> 
> I'm completely unsure whether suppressing operational attributes could
> harm slapd's internal operations in any kind? Ok thinking of denying
> contextCSN in replicated environments - hehe - the answer seems clear to
> me but what about the entryDN, hasSubordinates, and all the others...
> are they needed by slapd to operate correctly (possibly the operational
> attributes need is backend depending)?

'Needed by slapd to operate' is orthogonal to 'needed by nss_ldap to operate'.

> > Finally, you may also want to consider per-host credentials ... easiest
> > in a Kerberos environment.
> 
> Using sasl external or kerberos in combination with nss|pam_ldap's
> /etc/ldap.conf does not seem to improve security: the certificate's key
> needs to be world readable

Not necessarily.

> so any interested user can take the key and
> the certificate to bind "-Y EXTERNAL" to investigate the posixAccount
> users (and - I'm not sure - the same should apply to kerberos
> system/server tickets which needs to be world readable, too).

Not necessarily. See 'use_sasl' and 'root_use_sasl' options. If users are 
getting tickets on login, and you have 'use_sasl', user lookups will use their 
own privileges (if you have appropriate mapping from the SASL identity to 
their DN on the LDAP server).

> > Did you read the nss_ldap documentation?
> >
> > (Aaron already replied, but the fact that nss_ldap supports what you
> > wanted originally was not covered).
> 
> In my opinion that's not sure.
> 
> BTW and in regard to the "just for fun section", mentioned above:
> nss|pam_ldap has obvious design deficits therefore "nss_ldapd" has been
> developed and the related "slapo-nssov" is currently in development.
> These two approaches represent another level of indirection and seem to
> solve the above described general problems regarding the
> "quasi-anonymous" access because the nss part can be run in privileged
> user context where the bindDn/bindPw is probably kept more secure.

But, using nscd with nss_ldap achieves the same. Now, using nscd (or, maybe 
nss_ldap with nscd ...) does come with its own issues ...


> nss_ldapd seems to be quite stable. nssov is in the contrib branch of
> slapd and need to be compiled manually. Possibly one should give them a
> try instead of betting on a dead horse (nss_ldap)...

But, the privilege issue isn't the biggest reason.

Regards,
Buchan