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