OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos

[Douglas E. Engert]

"Henry B. Hotz" wrote:
> 
> I don't disagree with your proposal at all.  Sounds good.  It should
> make it easier to fix/change things in the future.
> 
> But. . .
> 
> Isn't the reason this keeps coming up that AFS client doesn't
> (can't?) behave like a normal Kerberos application and just get it's
> own service ticket when it needs one (based on an existing tgt)?  The
> real reason this doesn't happen is that tickets are stored in a file
> in /tmp, but it's a different set of file system code inside the
> kernel that would need to access it to request the service ticket.

Yes sort of. DCE/DFS had this capability. The AFS kernel mods would still 
need to associate the ticket cache to use when it needs to get a token. 
This is normally kept in the  KRB5CCNAME environment variable, which 
is only available to the application code. 

DCE/DFS addressed the problem, by keeping the ticket cache in
/opt/dcelocal/var/security/creds/dcecred_nnnnnnnn where nnnnnnnn was
the PAG number. The daemon (like sshd) still had to get the PAG, and 
set the KRB5CCNAME to point at the cache just in case it was needed by
some Kerberos application.   

DCE used only K5, AFS at that time use K4 and is just now starting to
convert to K5.  

> 
> Can't we figure a way to just make the kernel module get the service
> ticket (token) automatically, or fail if there is no tgt?  That would
> make the whole problem go away and AFS would no longer need the
> special attention it does now.

Yes it could, but it would be a lot of work. There are only a handfull
of deamons that need to get a PAG and token: sshd, ftpd, rlogind, 
telnetd ... They still need to save the forwarded credential too.   
Web servers too, there you might want a token associated with a thread.
So what is the tradoff? NFSv4 will have similiar problems, can AFS
and NFSv4 use the same PAG? (DCE/DFS and AFS used the same PAG
on some systems.)

> 
> I note that on MacOS X tickets are stored in a MACH "security
> context" which acts a lot like a PAG.  Furthermore it's accessible
> inside the kernel.  Doesn't Windows have some similar in-memory
> storage mechanism?
> 
> Has anyone thought about how congruent PAGs and terminal sessions
> are?  I think X11 defined the latter, and Kerberos has tried to tie
> in to them rather than import the PAG concept.

Any authenticated file system will have the same problem, be it 
AFS, DFS, NFSv4... These was some discussion of PAGs on one of the 
Linux mailing lists. The question came of what are the credentials
for accessing the local filesystem or older NFS. I would say it was the
fact that the process was running under a UID. 


> 
> At 11:21 AM -0600 1/26/04, Douglas E. Engert wrote:
> >Rather then implementing kafs in MIT Kerberos, I would like to
> >suggest an alternative which has advantages to all parties.
> >
> >The OpenSSH sshd needs to do two things:
> >    (1) sets a PAG in the kernel,
> >    (2) obtains an AFS token storing it in the kernel.
> >
> >It can use the Kerberos credentials either obtained via GSSAPI
> >delegation, PAM or other kerberos login code in the sshd.
> >
> >The above two actions can be accomplished by a separate process,
> >which can be forked and execd by the sshd and passed the environment
> >which may have a KREB5CCNAME pointing at the Kerberos ticket cache
> >Other parameters such as the home directory could also be passed.
> >
> >
> >This would then allow simple code in OpenSSH that does not depend
> >on OpenAFS, Hiemdal or MIT code to fork/exec the process that does
> >all the work. This would be called by the process that would
> >eventially become the user's shell process and is run as the user.
> >
> >OpenSSH could be built on systems that may or may not have AFS
> >installed and run on a system with or without AFS.  The decision
> >is based on the existence of the executable and any options
> >in sshd_config.
> >
> >In its simplest form, all that is needed is:
> >
> >   system("/usr/ssh/libexec/aklog -setpag")
> >
> >This is a little over simplified as there should be a test if the
> >executable exists, processing of some return codes, making sure the
> >environment is set, setting some time limit. etc. But the point is
> >there is no compile dependence on OpenAFS, MIT or Hiemdal by the
> >OpenSSH sshd, and any failure of the process will not effect the sshd.
> >
> >
> >
> >We have been using something like this for years which issues a
> >syscall to set a PAG for the current process, then fork/exec ak5log.
> >Our current mode to OpenSSH in session.c is as  simple as:
> >
> >   krb5_afs_pag_env(NULL, env);
> >
> >It is currently built with the MIT Kerberos code for historic reasons,
> >but could be seperate as it has no real dependency on the MIT code.
> >
> >I would hope that the members of the OpenSSH community who use OpenAFS,
> >Hiemdal and/or MIT could agree on a simple command line interface that
> >would encourage the builders of OpenSSH to always have this enabled.
> >
> >--
> >
> >  Douglas E. Engert  <DEEngert at anl.gov>
> >  Argonne National Laboratory
> >  9700 South Cass Avenue
> >  Argonne, Illinois  60439
> >  (630) 252-5444
> 
> --
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu

-- 

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