storing tickets in memory

[Donn Cave]

In article <21E548A5-BB02-11D8-AA2F-000A95909EE2 at mit.edu>,
 raeburn at MIT.EDU (Ken Raeburn) wrote:

> On Jun 10, 2004, at 09:11, Adam Denenberg wrote:
> > ok thanks for the info.  I did some reading and was basically thinking
> > of implementing kerberos here on our unix systems but read about some
> > security concerns about ticket credentials being stored in /tmp.
> > Meaning anyone with root can become another user and steal his/her
> > credentials.  How do people deal with this security issue?
> 
> By realizing that unless your OS significantly curtails the access 
> granted to root, the root user can look at users' shared memory 
> segments and local process memory, or run processes as the target user, 
> or modify system software to do things the users don't intend; so 
> basically, the game is over once the bad guy gets root access.

I think there may be two questions here.  One of them is
your bad guy scenario, which I suppose applies just as well
to my personal NetBSD desktop computer as to a host in the
basement with thousands of accounts.

The other is about per host level of assurance, where we
assume that every host's administrator is to some level a
bad guy.  Take for example a university campus -- many
departments will maintain their own sites, with a vast
range of security policies, and then there will be a lot
of one-of-a-kind hosts run by some professor's graduate
student, dormitory residents, who knows what all.  People
on campus are using these hosts, usually several of them
if any, and we would like to think that their access to
a residence hall computer wouldn't compromise their account
on the central site financial database.

I think this is actually a strong point of Kerberos
authentication, relative to the alternatives, because
you _don't have_ credentials on the remote host, so
it sort of doesn't matter what happens to you there.
Only the data you actually send to that host, or get
back from it, can be compromised, and your credentials
are not part of that data stream.  (I wish that were
easier for people to understand.)  In contrast, if you
use ssh or SSL to encrypt your password, for example,
it's going to be unencrypted on the remote end, and
your primary authentication key is utterly exposed to
the remote host's administrator.

So it seems to me, to answer `How do people deal with
this security issue?', I would start by asking, why is
it an issue?  Why does your user have credentials on
this host?  Maybe there's a good reason, like it's the
user's workstation which is obviously where the credentials
are going to be, but just to be aware that not every host
that plays the Kerberos game keeps user credentials.

And of course then there's the Kerberos authenticated
filesystem, but I don't know that can of worms/garden of
delights by experience.

   Donn Cave, donn at u.washington.edu