[OpenAFS] home on afs woes

[Douglas E. Engert]

Sergio Gelato wrote:

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

Yes I have been, I still believe this, and it appear to be working.
Solaris 10 ssh with their Kerberos for example. But sshd still has this
need to access .k5login early so we have lived with the symlink to a
seperate directory.

Its not just ssh that has this problem, it is any login deamon trying to
access the .k5login file, such as dtlogin.

Exactly where in the PAM stack do you want
> to obtain (and, if need be, discard) this extra token? pam_open_session()

I am not sure. It has to be after the GSSAPI or pam_authenticate has a TGT
(which could have been via keyboard interactive or at the console) but before
the krb5_kuserok is called.

Jeff's approach of using the host principal to get a token for the host is a half
way approach that would keep the .k5login from having to be world readable, but
does require the host to be added to ACLs and/or  groups. If that was implemented
we could use it as well.


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

Not sure, I have not looked. Only if a large part of the community was interested
in something like this, we could apporach the OpenSSH people with a proposal,
It should be generic enough to work for other file systems like NFSv4.

(A related problem is that a deamon using gss always does authentication and always
need to authiorization, but there was not gss_authz routines to use.) pam_sm_acct_mgmt
could be it.)

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

Yes...

> 
> 
>>>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.
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444