[2166] in Kerberos
Re: how does kerberos handle su utility
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Fri Sep 4 13:45:07 1992
Date: Fri, 4 Sep 92 13:22:26 -0400
From: "Barry Jaspan" <bjaspan@Athena.MIT.EDU>
To: nessett@ocfmail.ocf.llnl.gov (Danny Nessett)
Cc: kerberos@Athena.MIT.EDU, nessett@ocfmail.ocf.llnl.gov
In-Reply-To: [2164]
You can sort of achieve what you want using ksu in its current or a
modified form, but I don't think you want to.
In its distribution form, ksu requests a ticket-granting ticket for
<username>.root, checks whether that user is in root's .klogin file,
and if so creates a root shell just like su. (If the machine has an
rcmd.<hostname> srvtab, ksu uses it to verify the response from
Kebreros; otherwise, the response can be spoofed and ksu becomes a
security hole.)
So, for your scenario, I think this is what you would like: (a) user
on host A gets kerberos tickets, (b) user logs in via kerberos rlogin
to host B, (c) user run ksu to become root on host B. This assumes
that the user cannot or does not want to just rlogin to host B as root
in the first place, which would probably make more sense.
There are two problems with this scenario. (1) Kerberos rlogin does
not propagate tickets, so in step (c) the user will not have tickets
for ksu to use; the user will have to type a password. (2) In its
current form, ksu always gets a *new* ticket granting ticket for
username.root and therefore always prompts for a password, even if the
current KRBTKFILE contains a tgt for that user. I consider this a
bug, but haven't thought about it enough to be really sure that it is
one.
Problem (2) can be fixed by modifying ksu or using an encrypted
rlogin. Problem (1) can only be fixed by using Kerberos V5, which has
forwardable tickets, or by using a "remote kinit" system. Neither
will be trivial.
I recommend logging in as root in the first place. Kerberos is not
meant to perform local password validation.
Barry
