home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / protocol / kerberos / 670 < prev    next >
Encoding:
Text File  |  1992-09-03  |  2.0 KB  |  47 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!ATHENA.MIT.EDU!bjaspan
  3. From: bjaspan@ATHENA.MIT.EDU ("Barry Jaspan")
  4. Subject: Re: how does kerberos handle su utility
  5. Message-ID: <9209041722.AA22200@bill-the-cat.MIT.EDU>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Fri, 4 Sep 1992 17:22:26 GMT
  9. Lines: 36
  10.  
  11.  
  12. You can sort of achieve what you want using ksu in its current or a
  13. modified form, but I don't think you want to.
  14.  
  15. In its distribution form, ksu requests a ticket-granting ticket for
  16. <username>.root, checks whether that user is in root's .klogin file,
  17. and if so creates a root shell just like su.  (If the machine has an
  18. rcmd.<hostname> srvtab, ksu uses it to verify the response from
  19. Kebreros; otherwise, the response can be spoofed and ksu becomes a
  20. security hole.)
  21.  
  22. So, for your scenario, I think this is what you would like: (a) user
  23. on host A gets kerberos tickets, (b) user logs in via kerberos rlogin
  24. to host B, (c) user run ksu to become root on host B.  This assumes
  25. that the user cannot or does not want to just rlogin to host B as root
  26. in the first place, which would probably make more sense.
  27.  
  28. There are two problems with this scenario.  (1) Kerberos rlogin does
  29. not propagate tickets, so in step (c) the user will not have tickets
  30. for ksu to use; the user will have to type a password.  (2) In its
  31. current form, ksu always gets a *new* ticket granting ticket for
  32. username.root and therefore always prompts for a password, even if the
  33. current KRBTKFILE contains a tgt for that user.  I consider this a
  34. bug, but haven't thought about it enough to be really sure that it is
  35. one.
  36.  
  37. Problem (2) can be fixed by modifying ksu or using an encrypted
  38. rlogin.  Problem (1) can only be fixed by using Kerberos V5, which has
  39. forwardable tickets, or by using a "remote kinit" system.  Neither
  40. will be trivial.
  41.  
  42. I recommend logging in as root in the first place.  Kerberos is not
  43. meant to perform local password validation.
  44.  
  45. Barry
  46.  
  47.