[3321] in Kerberos
Re: What is Kerberized NFS?
daemon@ATHENA.MIT.EDU (Dan Geer)
Mon May 23 13:54:30 1994
To: rsalz@osf.org (Rich Salz)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "23 May 1994 15:54:56 GMT."
<2rqjkg$ppb@paperboy.osf.org>
Date: Mon, 23 May 1994 13:34:36 -0400
From: Dan Geer <geer@cam.ov.com>
grpjl@iastate.edu (Paul J Lustgraaf) writes:
>In most cases root can still pretend to be a
>user by picking up the ticket from the /tmp directory (or wherever).
>Various ways around this have been proposed, but I don't know that
>anything has ever been agreed on.
Yes, this is a well-known problem with the reference implementation of
Kerberos. It's part of the general design space that the local host
must be trusted. Athena solved this problem primarily by not having
multi-user machines.
OSF DCE DFS stores a users credential in the kernel, but this does not
protect them from anyone who can read /dev/kmem or its equivalent.
Given the common Un*x platform, this is probably an intractable problem.
/r$
"Athena solved this problem primarily by not having multi-user machines."
might better be stated as
"Athena solved many problems by not having multi-user machines, and
security was one of those problems."
That point aside, I submit that a corrupt superuser will be able to
violate the user's sanctity in many more ways than reading out the
ticket cache. For example, why not just read the password keystrokes
as they are typed? Why not just read everything typed and read back?
What is, in fact, really protected with a corrupt superuser on board?
I'd submit nothing is. As always, where there is booty, there is will
and where there is will, there is a way. At some point, you have to ask
yourself: "Self, if a corrupt superuser can do anything he damned well
pleases, what's the added value of keeping the ticket cache out of
reach?"
I'm not trying to attack r$'s point in any way, but given the design
constraints of Athena, viz.
user transparency (type password at login only, and avoid the
costs of a "security culture"), and
impeccable password handling (minimum retention in typed form,
immediate conversion to a time-contained proxy, no cleartext
on the wire, and no cleartext in memory other than a moment
in the tty input buffer)
there is not much else you can do in the conventional computing
environment.
Yes, fingerprint readers in every key top might be better (for some
value of better) as might carrying your AFS volume and your own cpu chip
on a credit card, relying on the desktop only for networking and a
display. So far as I know, that is the level of change required to
remove the issue of trust and its propagation (the coin of security)
from machines that you interact with and yet do not perpetually,
endlessly and infallibly oversee.
--dan
