dchen@is.Morgan.COM (Dave Chen) (02/28/91)
Hi,
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.
What security measures do you have in preventing this possible
breach?
Security Adminstration
Dave Chen tytso@ATHENA.MIT.EDU (Theodore Ts'o) (02/28/91)
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.)
- TedGALINA@IBM.COM ("Galina Kofman") (02/28/91)
***** Reply to your note of: Wed, 27 Feb 91 14:51:08 ********************* So, how does Athena distribute srvtab files? Galina
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (03/01/91)
Date: Wed, 27 Feb 91 15:20:02 EST From: "Galina Kofman" <GALINA@IBM.COM> So, how does Athena distribute srvtab files? We send the files over encrypted somehow. There are many ways to do this, but here's one: This assumes that you have a version of rlogin which supports DES encryption of the data stream. You would then be able to use a program to encrypt the srvtab file (it would be OK to type the password over the net, since you would be logged into the Kerberos server over an encrypted channel). You could then FTP the encrypted srvtab file to the destination machine, walk over to the destination machine, and decrypt the srvtab file while being logged in directly to the desintation machine. The reason why you wouldn't be able to get an encrypted rlogin channel to the destination machine is that this requires a srvtab, and the destination machine wouldn't have one yet. - Ted
galina (03/02/91)
> > > Date: Wed, 27 Feb 91 15:20:02 EST > From: "Galina Kofman" <GALINA@IBM.COM> > > So, how does Athena distribute srvtab files? > > We send the files over encrypted somehow. There are many ways to do > this, but here's one: This assumes that you have a version of rlogin > which supports DES encryption of the data stream. You would then be > able to use a program to encrypt the srvtab file (it would be OK to type > the password over the net, since you would be logged into the Kerberos > server over an encrypted channel). You could then FTP the encrypted > srvtab file to the destination machine, walk over to the destination > machine, and decrypt the srvtab file while being logged in directly to > the desintation machine. The reason why you wouldn't be able to get an > encrypted rlogin channel to the destination machine is that this > requires a srvtab, and the destination machine wouldn't have one yet. > > - Ted
qjb@ATHENA.MIT.EDU (03/02/91)
> So, how does Athena distribute srvtab files? > > We send the files over encrypted somehow. ... Actually, we often don't bother sending the srvtab over encrypted at all. We often simply copy the srvtab into a protect filesystem and copy it to the machine all in the clear. Then, once it's there, we run krsvutil change to change the keys via the admin protocol. This is analogous to giving a user an initial password and telling him/her to change it immediately. As you can imagine, there are quite a number of ways of doing this. I wrote a fairly program to generate srvtabs on the server machine directly via the admin protocol. The kerberos admin logs into the server (presumably physically at the machine), and types his admin password to this client which then uses the admin protocol to create new principals with random keys and write them into a srvtab file in the correct format. This program is not in the kerberos release because I wrote it after development on kerberos V had already started. If you are interested in this utility, feel free to send me personal mail. (I'm sure that if there is a problem with my giving it away, someone on this end will tell me so... :-) ) Jay Berkenbilt Project Athena
tytso@ATHENA.MIT.EDU (Theodore Ts'o) (03/02/91)
From: qjb@ATHENA.MIT.EDU Date: Fri, 1 Mar 91 16:46:39 -0500 Actually, we often don't bother sending the srvtab over encrypted at all. We often simply copy the srvtab into a protect filesystem and copy it to the machine all in the clear. Then, once it's there, we run krsvutil change to change the keys via the admin protocol. This is analogous to giving a user an initial password and telling him/her to change it immediately. People should note that, under this method, it is theoretically possible for someone with a Network sniffer to grab the srvtab as it passes by via FTP or NFS traffic, and then be able to use the knowledge of that key to figure out what the service key was changed to by spying on the ksrvutil's protocol exchange with the admin server. So this method doesn't really add that much security against a really determined (and knowledgable) attacker. People may want to decide that this amount of security is "good enough"; but they should be consciously aware of this decision. - Ted
Galina (03/02/91)
> > > > > > Date: Wed, 27 Feb 91 15:20:02 EST > > From: "Galina Kofman" <GALINA@IBM.COM> > > > > So, how does Athena distribute srvtab files? > > > We send the files over encrypted somehow. There are many ways to do > this, but here's one: This assumes that you have a version of rlogin > which supports DES encryption of the data stream. You would then be > able to use a program to encrypt the srvtab file (it would be OK to type > the password over the net, since you would be logged into the Kerberos > server over an encrypted channel). You could then FTP the encrypted > srvtab file to the destination machine, walk over to the destination > machine, and decrypt the srvtab file while being logged in directly to > the desintation machine. The reason why you wouldn't be able to get an > encrypted rlogin channel to the destination machine is that this > requires a srvtab, and the destination machine wouldn't have one yet. > > - Ted > Sorry for the previous append. Ted, do you mean that each user has to come do the database administrator and send srvtab file to her/his machine? Or does database administraotr has to come to each user's machine to decrypt srvtab? Thank you. Galina.. POST Newsgroups: comp.protocols.kerberos Subject: Re: srvtab on client machines From: Galina > > > > > > Date: Wed, 27 Feb 91 15:20:02 EST > > From: "Galina Kofman" <GALINA@IBM.COM> > > > > So, how does Athena distribute srvtab files? > > > We send the files over encrypted somehow. There are many ways to do > this, but here's one: This assumes that you have a version of rlogin > which supports DES encryption of the data stream. You would then be > able to use a program to encrypt the srvtab file (it would be OK to type > the password over the net, since you would be logged into the Kerberos > server over an encrypted channel). You could then FTP the encrypted > srvtab file to the destination machine, walk over to the destination > machine, and decrypt the srvtab file while being logged in directly to > the desintation machine. The reason why you wouldn't be able to get an > encrypted rlogin channel to the destination machine is that this > requires a srvtab, and the destination machine wouldn't have one yet. > > - Ted > Sorry for the previous append. Ted, do you mean that each user has to come do the database administrator and send srvtab file to her/his machine? Or does database administraotr has to come to each user's machine to decrypt srvtab? Thank you. Galina.
smb@ulysses.att.com (03/05/91)
Sorry for the previous append. Ted, do you mean that each user has to come do the database administrator and send srvtab file to her/his machine? Or does database administraotr has to come to each user's machine to decrypt srvtab? Thank you. Galina.. I think we have a misunderstanding here. In the environment for which Kerberos was designed, that's a non-issue. In general, workstations neither have nor need srvtab files, because they do not provide any services to the user community. In effect, they are very smart terminals (or interaction servers, if you prefer), with a substantial amount of computing power. A person sitting at such a workstation may want to access files that are stored remotely; for this, that person must somehow present credentials. But the workstation itself has no per-user files; it simply has the skeleton of a system on its local disk. And that local disk is, for all practical purposes, read-only. (For implementation reasons, it probably is not physically read-only.) When I visualize the Kerberos model, I tend to think of a large room filled with keypunches. (Yes, I know; my age is showing....) You, as a user, might prefer one keypunch over another. (Back when I used such things, I kept track of which keypunches had all of their starwheels intact.) But the ultimate host neither knew nor cared which one I used. Nor did I ever try to access the keypunch's drum card from the host. It's the same with Kerberos, at least as deployed at MIT. Not only is there no need to request services of a workstation, in general one cannot -- remote access is turned off. Thus, there are no services for which access is mediated by /etc/srvtab. The same reasoning explains why using /tmp for cached credentials is not as serious as it might appear at first glance: no one else has access to live tickets and their associated session keys. To be sure, I'd still prefer a different mechanism, but Kerberos workstations -- in their original environment -- minimize the exposure. There are, I believe, some private workstations at MIT. These may, if the owners wish, have network services. And there are certainly workstations on the martket whose computing abilities far exceed that of an overloaded central server; I can easily see why the owner of such a beast would want the ability to log in remotely. But if you want the privileges of a host, you have to accept the responsibilities: secure administration of /etc/srvtab files. (Note, too, that you have to deal with the database administrator anyway, so that entries for each service can be added to the Kerberos database.) It may be that your particular environment differs from MIT's. To the extent that it does differ, Kerberos may not be as good a fit. There are a number of issues; the maintenance of /etc/srvtab is only one of them. At the risk of repeating myself redundantly, a number of such issues are brought up in the Bellovin & Merritt Usenix paper; if you can't ftp it from research.att.com, I'll be happy to mail you a copy. --Steve Bellovin
don@ATHENA.MIT.EDU (03/06/91)
concerning workstation services, steve said: "There are, I believe, some private workstations at MIT. These may, if the owners wish, have network services. ... But if you want the privileges of a host, you have to accept the responsibilities: secure administration of /etc/srvtab files." please note that kerberos version 5 will allow client workstations to provide authenticated services ( like X service, rlogind, etc.) without need for clients' srvtabs. indeed, the mechanism will support such services on athena's own public workstations. p.s.: athena has 487 private workstations (~35% of total), as of today's count. -don davis, mit project athena staff