"Stealing" the credential cache

Ken Raeburn raeburn at MIT.EDU
Wed Aug 13 09:47:27 EDT 2008

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.


More information about the Kerberos mailing list