[OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos
Jeffrey Hutzelman
jhutz at cmu.edu
Mon Jan 26 16:28:21 EST 2004
On Monday, January 26, 2004 11:23:34 -0800 "Henry B. Hotz"
<hotz at 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+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the Kerberos
mailing list