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. rootbinddn and /etc/ldap.secret have no effect on standard nss operations invoked by unprivileged users.
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).
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 ;-))
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:
Regardless whether approach 1.) or 2.) (which you are forced to in case your directory does not support anonymous binds - e.g. MS AD) 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)?
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
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)?
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 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).
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.
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)...