Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!riacs!shelby!ATHENA.MIT.EDU!tytso
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Newsgroups: comp.protocols.kerberos
Subject: Re: srvtab on client machines
Message-ID: <9102271951.AA29192@tsx-11.MIT.EDU>
Date: 27 Feb 91 19:51:08 GMT
References: <9102271612.AA09887@9887>
Sender: news@shelby.stanford.edu (USENET News System)
Reply-To: tytso@ATHENA.MIT.EDU
Organization: Internet-USENET Gateway at Stanford University
Lines: 58


   Date: Wed, 27 Feb 91 11:12:30 EST
   From: dchen@is.Morgan.COM (Dave Chen)

       I work for Jo Goodson at Morgan Stanley & Co.  I like to know
   what methods do you have in securing the key in the /etc/srvtab
   on the client machines.  Our premise is that all client machines,
   who are maintain and controlled by their owner instead of our UNIX
   system administrators, are not securable.  It is very easy for 
   any knowlegeable unix user to gain root access if the owner does
   not maintain a tight security on his workstation.  Once a user	
   becomes root, he can get access to the /etc/srvtab file and use 
   it to get a ticket granting ticket from kerberos via ksrvtgt.  

At Project Athena, we generally don't put service keys on client
workstations.  You only need to place a key on a machine which is going
to be offerring some service.  If a machine can be easily compromised by
"any knowlegeable unix user", then there really isn't any point in
putting Kerboers mediated security on the workstation --- that's like
securing a barn door with a piece of string, and then using an extremely
expensive, hardened padlock to secure the string.

On the other hand, if you configure a workstation to have a service key
and offer Kerberos-mediated rlogin, NFS service, etc., you don't cause
any loss of security by doing so.  The service will of course be only as
secure as the workstation itself, but you don't lose anything by that.

As far as getting a ticket granting ticket from Kerberos via ksrvtgt,
yes, you can do that if you obtain control of /etc/srvtab, but that's
only for the service principal "{service}.{hostname}", i.e.,
"rcmd.thor".  That by itself will not cause any breach, unless
"rcmd.thor" is on some particular access control list, which in general
doesn't happen.  

It is also true that by obtaining possession of the /etc/srvtab for that
workstation, it is possible to forge tickets for any user (principal)
BUT ONLY FOR THAT SERVICE.  Since the workstation must have been
comprised to obtain the /etc/srvtab file, that service is already
compromised anyway, so it's no big deal.  Note that the program to forge
a ticket for a service given the service key is not in the kerberos
distribution.  I wrote such a program a long time ago, and argued that
it should be placed in the Kerberos distribution so that people realize
how important it is to keep the contents of /etc/srvtab secret (no
FTPing that file around in the clear!), but other people disagreed with
me as to the wisdom of including that program.

So in conclusing possession of the contents of /etc/srvtab allows you to
obtain or forge:

A) a ticket for the service principal for any other service.  (But
that's ok because the service principal shouldn't be on any access
control list).

B) a ticket for ANY principal for that particular service.  (But that's
ok because in order to obtain the /etc/srvtab file you must first
compromise the service itself.)

						- Ted