[OpenAFS] home on afs woes

[Russ Allbery]

Douglas E Engert <deengert@anl.gov> writes:

> The sshd could accept a forwarded ticket for the sole purpose of using
> it to get an AFS token so the sshd could access the .k5login file before
> the krb5_kuserok was called (There might be some other dot files that
> could also be accessed early.)  Getting this ticket early does not
> changed the security model, as the checking of the .k5login is to allow
> access to the local machine, not the AFS file system.  The forwarded
> ticket and token could be discarded if the krb5_kuserok fails.

The client is, understandably, not going to forward the ticket until after
the authentication step is complete, so what this basically means is
authenticating the user, accepting the forwarded ticket, and then
reauthenticating the user.  I guess it would be possible to do this, but
ew.  I'm guessing ew would be the OpenSSH upstream reaction too.

And this doesn't help with the PAM situation, where you don't get an AFS
token until after pam_setcred is called, which is after pam_authenticate,
and some programs only call pam_authenticate and never call the other PAM
functions.  This is probably wrong of them, but still, it shouldn't
introduce a security hole.

I suppose you could fall back on the standard PAM cheat of doing
everything in pam_authenticate and making everything else a no-op, but
that too breaks in other situations where people call pam_authenticate in
a different context than pam_setcred (OpenSSH is again at fault).

I don't see a good solution to this, unfortunately.  I wish that AFS
supported the directory lookup semantics supported in Unix with execute
but no read, but I can see why that would be rather hard to do.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>