[552] in Kerberos
Re: [Ted Anderson: principal name standards] and more
daemon@TELECOM.MIT.EDU (Kevin Fall)
Thu Dec 15 17:15:46 1988
From: kfall@OKEEFFE.BERKELEY.EDU (Kevin Fall)
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Cc: John T Kohl <jtkohl@ATHENA.MIT.EDU>,
In-Reply-To: Your message of Mon, 12 Dec 88 17:25:06 EST.
> To: John T Kohl <jtkohl@ATHENA.MIT.EDU>
> cc: Kerberos Users <kerberos@ATHENA.MIT.EDU>
> From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
> Subject: Re: [Ted Anderson: principal name standards]
> Date: Mon, 12 Dec 88 17:25:06 EST
>
> In-Reply-To: John T Kohl's message of Mon, 12 Dec 88 15:39:19 EST,
> <8812122039.AA04130@LYCUS.MIT.EDU>
>
> Another argument for:
>
> 2) it allows users to "delegate" or "partition" their priveleges by
> creating alternate names for some different "aspect" of their job.
> For example, there is another entry in the kerberos database, with a
> separate password, named "wesommer.root"; that identity, while
> associated with me as a person, has somewhat greater priveledges.
>
> Both of these are valuable uses; however, neither is any more than a
> naming convention.
>
I tend to agree this is really a naming convention. I am actually sort
of curious why the convention at Athena has become
person.root for a 'more priviledged version' of person. It seems to
me that for the super-user of a given machine, you really
want something more like root.machine1, root.machine2.
In fact, you may not want 'root instances' in the database
at all, keeping in mind that if the master key were compromised
you'd be that much worse off. We typically have a set
of some people with root priviledges on a group of machines
but additionally some people with root priviledges on only a
proper subset. It seems inconvenient to have to administer
new (principal,instance) pairs for these people.
Some other stuff:
The krb.conf file currently contains the *name* of the machine(s)
we will use for contacting the Kerberos server. This implies
a later gethostbyname() [found in send_to_kdc.c].
If you are running the nameserver
it is possible to be spoofed into returning the incorrect
inet address. (This is currently a problem with ruserok as well).
Until something better comes along, this should be changed to
a inet address.
Many people have mentioned the bug/feature of the lack of TGT
propagation across rlogin/rsh, etc. I would tend to think
that in the Athena model (most jobs originated from one's
workstation) this isn't as big a problem, but we tend
to originate processes from non-workstations very
frequently (no NFS yet).
Anyway, if the user were able to get TGT's from Kerberos for
an arbitrary IP address, there would then be an option
to rsh, rlogin, etc. as to whether or not you wanted a
new TGT to appear at the destination. The question is whether
or not it is secure to issue TGT's for arbitrary requested IP addresses
and also what mechanism should be used to acquire this ticket.
The answer to the first question appears to be yes. Since you
have control over the propagation of your TGT, you can keep
it from getting moved to machines you don't trust. You still
can't carry the ticket into a new realm, as you don't know
the TGS key there. If you are worried about some nasty
person on the local host grabbing the thing and taking it
to the IP address you've specified you've got other problems anyway.
For the 2nd question, the TGS should
probably just issue what you request based upon the authentication
info in your initial TGT.
How does rdist work at Athena, or is this a non-issue (I do
seem to remember hearing about some other type of software
update facility) ? We run it from cron, so I guess really
this comes back to the ticket lifetimes problem.
One way of getting around this problem is to have client
and server (e.g. for rdist and other 'system' processes)
have a common secret key and do encrypted updates. I am
using this currently to allow users to add themselves to the
kerberos system remotely if they have managed to log
in successfully.
Finally, has an admin. RPC been decided on yet?
- Kevin
Kevin R. Fall
Department of Computer Science
571 Evans Hall
University of California, Berkeley
Berkeley, CA 94720
UUCP: ...!ucbvax!kfall
ARPA: kfall@ucbvax.Berkeley.EDU
AT&T: (415) 642-3979
