"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.
Ken
More information about the Kerberos
mailing list