On Monday, January 26, 2004 11:23:34 -0800 "Henry B. Hotz" <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
