[Mageia-sysadm] [377] - add nssldap password handling

Tue Nov 23 15:50:42 CET 2010

On Tuesday, 23 November 2010 08:24:03 Luca Berra wrote:
+> On Mon, Nov 22, 2010 at 12:56:32PM +0100, Buchan Milne wrote:
+> >> +binddn uid=nssldap,ou=System Accounts,<%= dc_suffix %>
+> >> +bindpw <%= nssldap_password %>
+> >> 
+> >>  uri ldaps://ldap.<%= domain %>
+> >>  base <%= dc_suffix %>
+> >>  pam_lookup_policy no
+> >
+> >I would prefer if we can instead use:
+> >-"rootbinddn" in /etc/ldap.conf, not binddn
+> >-place password in /etc/ldap.secret
+> >-use nscd, so all LDAP access is as root (so, no need to expose passwords
+> >in files that must be world-readable), as a side-effect also avoiding
+> >problems with file descriptors used by any process doing a user lookup
+> >etc.
+> >
+> >Permissions on /etc/ldap.conf should be 0644, /etc/ldap.secret can be
+> >0600.
+> 
+> what is the real use of rootbinddn?
+
+Only practical use is preventing non-root users from discovering the proxy 
+user's password, which *may* have more privileges than their own account (or 
+some account they have compromised).
+
+> is there really any need to expose different information to NSS when
+> caller is uid 0?
+
+No, besides above. So, nss_ldap+nscd or sssd or nss-pam-ldapd or slapd+nssov 
+are equivalent here.
+
+> also the idea of a proxy user is flawed, it gives just about the same
+> security of opening anonymous read access.
+
+Using a proxy user means 'by users read' has some value ... note that we have 
+replaced all anonymous access with 'users' access.
+
+> With the added bonus that
+> changing the proxyuser password poses a risk of breaking things.
+
+How much is broken depends on how "proxy users" are managed. For now we are 
+going with per-host "proxy" users, and per-host per-application users for 
+applications, so if a host is compromised, its access can be revoked without 
+impacting other hosts or instances (more or less a Kerberos-style access).
+
+If this is too much overhead, we can consider other options.
+
+> since the info exposed to NSS is no big secret we can cope with it, but
+> i prefer leaving nss to anonymous binds and adding on ldap server (at
+> the end of access control)
+> 
+> access to dn.subtree="dc=mageia,dc=org"
+>         
+> attrs=@posixAccount, at posixGroup, at ipService, at ipProtocol, at ipHost, at ipNetwork,
+> @oncRpc, at nisNetgroup by peername.ip="127.0.0.1" read
+>          by peername.ip="x.y.w.z" read
+>          by * none
+
+Which leaves access from all non-root internet-facing applications open. While 
+there is not *much* of value there, I would prefer to try and protect 
+privilege escalation vectors.
+
+Regards,
+Buchan
+