Re: nslcd + GSSAPI basic design

[Arthur de Jong <arthur [at] arthurdejong.org>]

I don't know too much about Kerberos so others may be able to provide
more detailed information regarding that but I know a few things about
name lookups in general.

On Wed, 2013-04-10 at 16:56 +0000, Marc us wrote:
> No matter if I use nslcd/pam_ldap or sssd, the call to getent will use
> the hosts TGT (or whatever principal+keytab we have configured) for
> the LDAP bind operation instead of the already existing TGT created
> during the authentication process.

This is correct. The reason for this is that user names and other user
information is generally considered global information. In general the
libc nsswitch code has some assumptions that available user information
is the same for all processes and all users on the system. This is
especially true when using nscd.

> As an result of this behavior the statically configured principal must
> have permissions to lookup account information on the directory. From
> my understanding this is a wrong behavior as anyone would be able to
> enumerate the whole directory. I know that enumeration can be disabled
> but this won’t stop anyone with root access to retrieve a ticket using
> the keytab file and start an ldapsearch.

Indeed, with both nslcd or sssd you have a set of credentials for the
host to do the LDAP lookups and this needs to have enough privileges in
the directory to retrieve information on all the users and groups that
may be needed on the system.

> On a hosting environment where you can’t trust any root account this
> is a problem. Restricting the host principal to be able to retrieve
> only some authorized entries would be an administrative nightmare and
> would result in a large overhead for security checks on the LDAP
> servers. Allowing a user principal to retrieve its own account
> information and nothing else is a simple task without much overhead.

Using the user's credentials to do the lookups will cause problems for
other processes on the system. A lot of non-user processes may need to
look up user information. For example, cron may need to look up user
information, MDA needs to know home directory, root user doing ps on the
system would want see user names, etc.

More importantly, you have a bootstrapping problem: before the user can
authenticate you check whether the user exists (generally a process
running as root does this). Even if you would be able to implement a PAM
module that is able to authenticate users that don't have a numeric uid
before the authentication is complete, I doubt it would work in most
cases. I think the default PAM implementation does a username lookup
before starting the authentication and I expect many daemons (e.g. SSH)
also do this. It would be a very interesting problem to solve. ;)

Perhaps some parts of this can be accomplished with PADL's nss_ldap
which performs all lookups from the user's address space (which brings
with it a different challenge if you want to also do host-based
authentication with client-side SSL certificates).

In all cases you will probably not be able to use nscd, unless you have
a nscd version that supports a per-user cache.

I think Solaris has/had some support for username namspaces (not to be
confused with the numeric user namespace that have been implemented in
recent Linux kernels). I've seen some kernel patches/tricks in the past
that would limit a user to only seeing their own processes and the like
but I don't think it covers your use case. I don't think these
approaches prevent the root user from enumerating all users though.

I may be mistaken though and if anyone knows of a way to accomplish
this, I'm very interested.

Hope this helps a bit,

-- 
-- arthur - arthur@arthurdejong.org - http://arthurdejong.org --

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/