home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / kerberos / 672 < prev    next >
Encoding:
Text File  |  1992-09-07  |  3.3 KB  |  66 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!OCFMAIL.OCF.LLNL.GOV!nessett
  3. From: nessett@OCFMAIL.OCF.LLNL.GOV (Danny Nessett)
  4. Subject: my previous question refined
  5. Message-ID: <9209042231.AA21478@ocfmail.ocf.llnl.gov>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Fri, 4 Sep 1992 22:31:08 GMT
  9. Lines: 55
  10.  
  11.  
  12. Recently I asked a question about using su through a connection established
  13. by a Kerberized rlogin daemon. I have received a number of helpful responses
  14. for which I thank the authors. However, my question had a nuance that
  15. wasn't clearly expressed. Let me try again.
  16.  
  17. Suppose I want to bring up a machine that could only be accessed via
  18. Kerberos. This would require properly Kerberized r-tools, Telnet, FTP,
  19. etc. Now suppose that I am logged onto this machine and want to execute
  20. the su utility. Traditionally, this utility allows me to change to root
  21. access, if I have a root identity and know its password and it also
  22. allows me to change my identity to another user if I know his/her identifier
  23. and password. However, since this machine is completely Kerberized, the
  24. only password I know is my Kerberos password and this isn't stored in
  25. the /etc/passwd file that su accesses. In fact this file probably
  26. won't have any encrypted password at all.
  27.  
  28. Several responders suggest using a root password held by Kerberos to
  29. gain root privileges. This means passing your root password to
  30. the remote machine. To protect it, you probably want to logon originally
  31. by executing "rlogin -x". Of course, this means either knowing ahead of
  32. time you want to change to root, or (more likely) always executing "rlogin -x".
  33. The only question remaining for this option is whether ksu allows you
  34. to login directly as another user or whether you have to become root
  35. and then use su to do that. Of course, this option doesn't help if you
  36. Telnet to the machine.
  37.  
  38. Barry Jaspan points out that support of ksu could provide a security hole
  39. if the machine doesn't have a rcmd.<hostname> srvtab. That's another concern,
  40. but can be taken care of by proper administrative controls (of course it
  41. often happens that administration is sloppy).
  42.  
  43. Jon Rocklis suggests either using ksu or "rlogin -l root". The latter option
  44. doesn't work for Telnet.
  45.  
  46. Asokan says that Waterloo has something called kesc, that protects the
  47. root password as it travels to the remote machine. Interestingly, Waterloo
  48. has a system administrator who telecommutes, which is a concrete reason
  49. why the su problem is not just theoretical. I will look at the kesc
  50. documentation to see how it does this to determine if it can be used wit
  51. Telnet.
  52.  
  53. Finally, Jeff Schiller suggests having two identities within a Kerberos
  54. Realm, one for ordinary work and one for root work. When you want to
  55. do root work, you logoff the remote machine, su to root (which gets root
  56. access tickets) and then logon to the remote machine. I'm not sure, but
  57. I think this means that a user with root privilege has those privileges
  58. on all machines.
  59.  
  60. Of all these suggestions, it seems like ksu is the most workable except
  61. for the problem of passing your root password in the clear. If kesc
  62. works with Telnet, maybe even that problem is solved (again assuming
  63. ksu allows you to change directly to another user).
  64.  
  65. Dan Nessett
  66.