my previous question refined
Danny Nessett
Recently I asked a question about using su through a connection established
by a Kerberized rlogin daemon. I have received a number of helpful responses
for which I thank the authors. However, my question had a nuance that
wasn't clearly expressed. Let me try again.
Suppose I want to bring up a machine that could only be accessed via
Kerberos. This would require properly Kerberized r-tools, Telnet, FTP,
etc. Now suppose that I am logged onto this machine and want to execute
the su utility. Traditionally, this utility allows me to change to root
access, if I have a root identity and know its password and it also
allows me to change my identity to another user if I know his/her identifier
and password. However, since this machine is completely Kerberized, the
only password I know is my Kerberos password and this isn't stored in
the /etc/passwd file that su accesses. In fact this file probably
won't have any encrypted password at all.
Several responders suggest using a root password held by Kerberos to
gain root privileges. This means passing your root password to
the remote machine. To protect it, you probably want to logon originally
by executing "rlogin -x". Of course, this means either knowing ahead of
time you want to change to root, or (more likely) always executing "rlogin -x".
The only question remaining for this option is whether ksu allows you
to login directly as another user or whether you have to become root
and then use su to do that. Of course, this option doesn't help if you
Telnet to the machine.
Barry Jaspan points out that support of ksu could provide a security hole
if the machine doesn't have a rcmd.<hostname> srvtab. That's another concern,
but can be taken care of by proper administrative controls (of course it
often happens that administration is sloppy).
Jon Rocklis suggests either using ksu or "rlogin -l root". The latter option
doesn't work for Telnet.
Asokan says that Waterloo has something called kesc, that protects the
root password as it travels to the remote machine. Interestingly, Waterloo
has a system administrator who telecommutes, which is a concrete reason
why the su problem is not just theoretical. I will look at the kesc
documentation to see how it does this to determine if it can be used wit
Telnet.
Finally, Jeff Schiller suggests having two identities within a Kerberos
Realm, one for ordinary work and one for root work. When you want to
do root work, you logoff the remote machine, su to root (which gets root
access tickets) and then logon to the remote machine. I'm not sure, but
I think this means that a user with root privilege has those privileges
on all machines.
Of all these suggestions, it seems like ksu is the most workable except
for the problem of passing your root password in the clear. If kesc
works with Telnet, maybe even that problem is solved (again assuming
ksu allows you to change directly to another user).
Dan Nessett
Mark W. Eichin
> the remote machine. To protect it, you probably want to logon originally
> by executing "rlogin -x". Of course, this means either knowing ahead of
> time you want to change to root, or (more likely) always executing "rlogin -x".
link at the other end is far more of a bottleneck than DES encryption
will ever be. I always use encrypted rlogin.
Note that the 91.03.25 version of telnet does support toggling
encryption on and off, inbound and outbound, if you do notice the
performance.
> Jon Rochlis suggests either using ksu or "rlogin -l root". The latter option
> doesn't work for Telnet.
Actually, when the aforementioned telnet is invoked as rlogin,
it *does* work. (It seems not to work for root, but there is no
problem switching to other users based on the .klogin file; failing as
root in particular appears to be simply a bug.)
> access tickets) and then logon to the remote machine. I'm not sure, but
> I think this means that a user with root privilege has those privileges
> on all machines.
The only machines that a user with a root instance has root
access to (via rlogin or ksu) are those with their root instance
listed in the /.klogin file. This could easily be no machines at all;
root access has nothing to with the name of the instance, all that
matters is that the name of the principal given is on the access
control list.
> Barry Jaspan points out that support of ksu could provide a security hole
> if the machine doesn't have a rcmd.<hostname> srvtab. That's another concern,
If the machine is "tightly kerberized" as you describe, then
without such a srvtab, you won't be able to get in at all, other than
from a directly wired terminal, so ksu won't be a threat. It is still
important to be careful about making ksu available on "client only"
machines that don't have such a srvtab.
> do root work, you logoff the remote machine, su to root (which gets root
> access tickets) and then logon to the remote machine. I'm not sure, but
I don't think Jeff implied that it was necessary to log off;
most of us use window systems of some sort, so popping up an
additional connection isn't a hassle.
_Mark_ <eic...@cygnus.com>
Cygnus Support --
"Cygnus Network Security"
Glen Zorn
Several responders suggest using a root password held by Kerberos to
gain root privileges. This means passing your root password to
the remote machine. To protect it, you probably want to logon
originally
by executing "rlogin -x". Of course, this means either knowing ahead of
time you want to change to root, or (more likely) always executing
"rlogin -x".
The only question remaining for this option is whether ksu allows you
to login directly as another user
It does.
or whether you have to become root
and then use su to do that. Of course, this option doesn't help if you
Telnet to the machine.
Try the new, improved telnet, with Kerberos authentication *and* DES
encryption! ;-)
Asokan says that Waterloo has something called kesc, that *protects*
*emphasis mine*
the root password as it travels to the remote machine.
Personally, I'm not sure I'd want the root password floating about on the net,
"protected" or not. Passwords are relatively long-lived items -- a wiley
cracker would have something akin to forever to break the encryption, if the transmission was captured. That said, kesc does sound interesting. I'd like to
take a look at it myself.
Finally, Jeff Schiller suggests having two identities within a Kerberos
Realm, one for ordinary work and one for root work. When you want to
do root work, you logoff the remote machine, su to root (which gets
root
access tickets) and then logon to the remote machine. I'm not sure, but
I think this means that a user with root privilege has those privileges
on all machines.
I'm not sure, but I suspect that Jeff is suggesting the use of a root instance.
If that is the case, then only those machines on which you have a root instance
(i.e., nesset...@ocfmail.ocf.llnl.gov) listed in /.klogin would allow you to rlogin as root. By the bye, if you used ksu on the local host, you wouldn't
need to kinit as root, since ksu gets an rcmd ticket itself as a safeguard.
Of all these suggestions, it seems like ksu is the most workable except
for the problem of passing your root password in the clear. If kesc
works with Telnet, maybe even that problem is solved (again assuming
ksu allows you to change directly to another user).
Actually, I think Jeff's suggestion is by far the most secure, though a bit
cumbersome.
~ Glen
Glen Zorn Network Security Analyst
gl...@OCSG.COM Open Computing Security Group