[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Posix group with /etc/ldap.conf read priv
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)...