[OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos

[Jeffrey Hutzelman]

On Monday, January 26, 2004 11:23:34 -0800 "Henry B. Hotz" 
<hotz@jpl.nasa.gov> wrote:

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

No; it's not that simple.  Making the cache manager access ticket files 
would require first gaining a Kerberos dependency that we don't already 
have, and then importing lots of code into the kernel, much of which 
depends on network and filesystem interfaces that simply don't exist in 
kernel mode.

Worse, it would not solve the problem.  The trouble here is not that AFS 
tokens are stored in a kernel data structure instead of a file.  It's that 
they are indexed by a value which must be set on login, inherited from each 
process by its children, and must not be changeable by the user (to prevent 
token stealing).  OpenSSH loses not because you need special code to set 
tokens, and not even because you need special code to generate a new PAG -- 
those things can be done by a PAM module.  OpenSSH loses because the PAM 
session module gets called outside the inheritance chain of the user's 
shell, which means it can't set a PAG or anything else that is inherited 
across a fork (e.g. groups, environment variables, resource limits, etc etc 
etc).


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

Windows' own credentials are managed by a trusted component (the LSA), 
which keeps a credential cache associated with each login session.  This 
cache is read-only -- you can ask the LSA to obtain new tickets on your 
behalf, but you can't give it tickets to remember for you, and AFAIK you 
can't have more than one cache per login session.

Both Windows and MacOS X have mechanisms for managing a security context 
which is inherited between processes, cannot be "stolen", and is 
independent of the mechanisms used for terminal control and session 
management.  Other UNIX platforms lack such a mechanism; this is the 
purpose served by the PAG mechanism introduced by AFS.  What is key is the 
existence of such a mechanism, not whether credentials are stored in a file 
or a kernel data structure or some trusted process.


> Has anyone thought about how congruent PAGs and terminal sessions are?

They're not.  They have similar properties, but they are _not_ congruent. 
For example, if you run an X11 session with many xterms, each terminal 
(xterm) is a separate session, but shares the same PAG.  You want this, so 
when you type 'klog' in one window, the resulting tokens are available in 
all windows.  OTOH, if you run an AFS-aware su, the resulting subprocess 
will have a new PAG (you don't want it to share tokens with other windows), 
but it must be in the same session, so it will get a SIGHUP if the terminal 
is closed.

One serious mistake is trying to overload the same inherited classification 
mechanism to perform more than one unrelated purpose.  This is why SVR4 
separates the concept of "process group" and "session" -- process groups 
and the concept of the controlling terminal alone were not sufficient for 
the task.


> I
> think X11 defined the latter, and Kerberos has tried to tie in to them
> rather than import the PAG concept.

AFAIK, the process group concept was introduced in BSD UNIX prior to 
4.3BSD, and the session concept was introduced in SVR4.  Neither was 
introduced by X11, which has no concept of terminals and thus no need to 
manage them, or by xterm, which used the existing pseudo-tty mechanism.

Kerberos in most cases stores credential caches in files; the location of 
the ccache file is stored in the environment, which is another set of 
properties which is inherited between processes (but one which the kernel 
knows precious little about, and whose contents are completely alterable by 
the user and thus cannot be trusted).  On certain platforms, Kerberos has 
indeed made use of PAG-like mechanisms provided by the operating system.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA