RE: nslcd + GSSAPI basic design

[Marc us <coboluxx [at] outlook.com>]

Hello Arthur,

many thanks for your valuable feedback. I think this is a very interesting 
topic.

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

Yes,  this makes totally sense from the OS point of view. 

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

Okay, I understand that there are some implications with this and that I 
possibly will be unable to implement it this way as to many software relies on 
the username/uid mapping. However, I can't see a real issue from the technical 
view. 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)). Basically it's the same as with MS Windows. 
On Windows the tasklist would simply show the users SID (from the process 
environment) because the name can't be resolved using an LDAP lookup with the 
current logged on users credentials. Internally the OS just cares for the SID 
as Unix cares for the UID. For an MDA you have many options (they all have some 
kind of virtual user support from what I know).

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

> 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. ;)

SSHD is currently a of show killer because it ignores the pam auth part with 
GSSAPI authentication. It does check for an passwd entry by its own but I can 
imagine that there would be an easy solution for this too. I did not look at 
the source but I think this is from the code that is normally used for Pubkey 
or password auth (check ~/.ssh/authorized_keys, ...) and all these other nifty 
ssh features you won't need with Kerberos in place.

> 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).

>From what I had understand this uses a static principal too instead of the 
>users ticket but I will take a deeper look on this.

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

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

This whole things is getting much more complicated than I initially thought it 
is. 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.

At the moment it looks to me like there is only one ugly approach. This would 
involve something like logging on with a Kerberos ticket to a locally known 
special account for the first time. 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). Of cause this will leave any account ever 
logged in on the local system even if the user has been revoked access to this 
system. Not a nice and far from perfect approach but it should work. 

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

Me too :)

Many thanks!

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