home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sgi / 16603 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  1.8 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!olivea!sgigate!sgi!rhyolite!vjs
  2. From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Net Services and backdoors
  5. Message-ID: <shabbi4@rhyolite.wpd.sgi.com>
  6. Date: 18 Nov 92 18:32:55 GMT
  7. References: <1992Nov18.162916.12717@tamsun.tamu.edu>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 39
  10.  
  11. In article <1992Nov18.162916.12717@tamsun.tamu.edu>, bpb9204@tamsun.tamu.edu (Brent) writes:
  12. > Hello, all.
  13. > 
  14. > We have a lab with SGIs, RS6Ks, and Suns, and some of the machines
  15. > have subtle network software problems.  Fortunately, I've been
  16. > able to track down all the problems (except for mail).
  17. > 
  18. > One minor problem was that you could not "finger @machine" because
  19. > finger would print "connection refused."  This simple problem boiled
  20. > down to "machine" (an SGI) running fingerd as user "guest."  Guest
  21. > was a nonexistent user on the system.  I edited /usr/etc/inetd.conf
  22. > to change the finger entry to run as root.
  23. > 
  24. > Now my main question.  Which of these network services do you NOT
  25. > want to run as root?  Does finger have any backdoors or other holes
  26. > into the system?
  27. > 
  28. > Is there documentation someplace about which network services can
  29. > spawn shells or otherwise allow somebody access to your system
  30. > (by not using telnet/rlogin)?
  31. > 
  32. > I'd appreciate any comments you may think of.
  33.  
  34.  
  35. There are no known security problems with the IRIX fingerd, but
  36. the same could have no doubt been said about fingerd for VAX's
  37. and Sun's in 1986.  Remember the "worm"?
  38.  
  39. It is not generally a good idea to run programs with more permission
  40. than they need.
  41.  
  42. Instead of removing the "guest" entry from /etc/passwd, I would
  43. make it present but unusable:
  44.  
  45. guest:off:998:998:Guest Account:/dev/null:/bin/true
  46.  
  47.  
  48.  
  49. Vernon Schryver,  vjs@sgi.com
  50.