On Aug 13, 2008, at 07:55, E. Braun wrote: > Is this the expected behaviour, that the root user of a client (the > user has > no interactive access to the Kerberos and AFS servers) can use a > copy of the > credentials cache for getting an afs token?
Yes. Finding a place where the superuser cannot access a user's credentials (either directly or by changing uid to the user, or in an extreme case, attach a user's process via ptrace or whatever, as if under a debugger, and extract the authentication info from the user's process) is a system-specific problem and not always possible; it requires that the OS enforce restrictions on a superuser account. I'm not familiar with whether the keyring code in Linux (optionally used in recent MIT Kerberos releases) enforces such restrictions. If we could hook into AFS process authentication groups, that might help raise the bar as well, to prevent casual copying but not the ptrace attack, but only on systems where AFS is installed (specifically implementations with PAGs). Ken Hornstein has patches around to use an extra, high-numbered file descriptor inherited across processes, with the process fd limit lowered to just below that fd, which restricts access to a login session (aside from the ptrace attack), but requires modifications to the login process to set up this file descriptor, and requires that no process close all the high-numbered file descriptors (which I gather is actually fairly uncommon to do above the lowered file descriptor limit). BTW, comp.protocols.kerberos is relayed to/from a mailing list; directing followups to a different newsgroup is not going to work for some readers. Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos