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
