[OpenAFS] home on afs woes

[Sergio Gelato]

* Douglas E. Engert [2006-01-04 14:19:56 -0600]:
> Russ Allbery wrote:
> >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.

If I remember correctly, you've been advocating the removal of explicit
AFS support code from OpenSSH in favour of relying on PAM to obtain the
AFS tokens. (Vendors shouldn't be required to ship AFS-aware sshd's,
or something to that effect.) Exactly where in the PAM stack do you want 
to obtain (and, if need be, discard) this extra token? pam_open_session() 
is clearly too late for this, which is a pity.

Is there even a single PAM call between the end of gss_accept_sec_context() 
and the call to ssh_gssapi_userok() ? I guess not.

> >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.
> 
> Its part of the GSSAPI exchange, to get the forwarded ticket and is done
> before the krb5_kuserok is called outside of gssapi.

True, reauthentication would not be necessary. OpenSSH upstream may
still balk at the additional #ifdef USE_AFS , though.

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

This is straying off-topic, but I'd argue that the default behaviour of
a PAM module should still be the correct one: call krb5_kuserok() from
pam_sm_acct_mgmt() only. Then one can add options to work around bugs in
important applications. As far as the screensavers' not running the
account stack, I'd be more worried about what happens when a Kerberos
password has just expired than about krb5_kuserok() being skipped:
after all, the initial login must have run the account stack successfully.

> I know pam is a mess and aplications don't call it correctly.

Worse: there seems to be no consensus on how to call it correctly.

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

Would it buy you all that much? We're talking about well-known file
names here, it's easy to test for their existence one by one even
without the convenience of readdir().

> Not sure if that would even help. The point I would like is that the 
> .k5login
> is only readable if I as a user permit it. i.e. by me forwarding a ticket to
> some machinhe so it can read it or by me adding the host on to the ACL of 
> the
> directoty.

I as a user may want to allow the host to read .k5login during
authentication but deny such access to other unprivileged users 
of the same computer.

That seems to call for a host.hostname entry in PTS and a way for sshd
etc. to obtain an AFS token for that, discarding it (e.g. by changing PAGs)
before control is handed to the user... OK, I see that Jeffrey Altman
has beaten me by a few minutes.