Re: nslcd + GSSAPI basic design

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

On Thu, 2013-04-11 at 01:43 +0000, Marc us wrote:
> From my understanding of the Unix process environment the UID is the
> only requirement. If this UID is resolvable to a name or not is just
> cosmetic (beside of the fact that some applications like cron may use
> the reverse mapping (crontab filename to UID)).

The problem is indeed not in the kernel or core functionality. I think
the only part of the kernel that I know of that deals with user names is
NFSv4 (perhaps other network-based filesystems also need to do username
translation). The real problem is in the applications.

> > 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). 
> 
> Yes, this was my first problem but the solution was quite simple.
> pam_krb5 has an option called no_user_check which prevents any passwd
> lookups. The pam authentication parts works perfectly with this in
> place. The problem starts with the account part where ldap should kick
> in.

I think this mostly depends on the service that is calling PAM. Most
services expect to do a setuid() after authentication so may check
before starting the PAM authentication.

> I have no clue about nscd internals but as long as nscd gets the UID
> of the caller this should not be that difficult to implement?

By default nscd runs as root lookups that are initiated by normal user
processes are actually executed as root.

> There are many other issues too like root being able to "hijack" any
> krb credential cache file which is usually stored on /tmp. I've read
> that there are some intentions for an kernel in memory keystore on
> recent kernels which could be used for this too.

It shouldn't be difficult for root to read kernel memory (/dev/mem)
unless SELinux is used so in general, any user private information is
still available to root.

> Once logged in using this special account you can query LDAP with the
> authenticated principal to retrieve UID/GID/Home, creating a local
> account temporarily and changing the user to this account (this would
> work with sshd too).

I think there are some solutions available for generating local accounts
from an LDAP server (no first hand experience though).

I had one idea that may provide a little bit security: you could add a
sizelimit (of 1) to the LDAP server. That way you would only be able to
query one user at a time.

This makes enumerating users slightly more difficult. This is obviously
not a foolproof solution because you could still enumerate all users by
querying all numeric uids in succession. But it would avoid most
accidental leaks of information.

This could break applications that routinely enumerate all users (I
think some desktop applications do that) and could cause problems for
the group membership lookup at login.

-- 
-- 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/