home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / security / misc / 2589 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  3.2 KB
  1. Path: sparky!uunet!usc!nic.csu.net!nic.csu.net!nntp
  2. Newsgroups: comp.security.misc
  3. Subject: Re: Unix Viruses. Are there any??
  4. Message-ID: <1993Jan23.202734.3921@nic.csu.net>
  5. From: oleg@gd.cs.csufresno.edu
  6. Date: 23 Jan 93 20:27:29 PST
  7. Sender: oleg@gd.cs.csufresno.edu
  8. References: <1jotp8INNiu@matt.ksu.ksu.edu> <9302314.5488@mulga.cs.mu.OZ.AU> <1jrgcdINNgm9@cronkite.cisco.com>
  9. Organization: Computer Science Departement of California State University in Fresno
  10. Nntp-Posting-Host: gd.cs.csufresno.edu
  11. Lines: 49
  12.  
  13. In article <1jrgcdINNgm9@cronkite.cisco.com> ohansen@europe.cisco.com (Ove Hansen) writes:
  14. >In article <9302314.5488@mulga.cs.mu.OZ.AU> carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer) writes:
  15. >|>In article <1jotp8INNiu@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) writes:
  16. >|>>senetza@sigma.uleth.ca (Len Senetza) writes:
  17. >|>>
  18. >|>>>this assumes that root has . in its path, and how many root accounts
  19. >|>>>out there do?
  20. >|>>
  21. >|>>A scenerio like this assumes that the sysadmin is a pretty trusting person
  22. >|>>and probably already has large security holes in the system.
  23. >|>
  24. >|>a scenario like this assumes that the sysadmin should not be a sysadmin.
  25. >
  26. >Now, Remember that the majority of sysadmins are part-timers who have better
  27. >things to do in their company than tighten up the security holes that the
  28. >vendors leave in the systems they sell. In most small companies I have seen
  29. >where there are just a few Unix, VMS, OS/2, DOS, Mac or-whatever-boxes the
  30. >least computer-illiterate person is usually the person who is expected to
  31. >spend a couple of hours a day looking after the systems. It's unfair saying
  32. >that this sysadmin shouldn't be a sysadmin just because the vendors can't
  33. >be bothered making the systems more secure. Tell me the following: when I
  34. >install my shining new Sun desktop server option, is there a '.' in root's
  35. >path? Is there any access control on exported file systems? Is there a '+'
  36. >in /etc/hosts.equiv? The default security in a new installation should be
  37. >high, it then would be up to the sysadmin to open up his system to suit his
  38. >needs, instead of running the risk of having the system full of holes because
  39. >he hasn't known of them. If the system then was full of large security holes
  40. >I would agree with your statement, now you're shooting the pianist because
  41. >the piano-vendor sold the bar-owner a crap piano.
  42. >
  43.  
  44. Actually, I think  the system  should come as it comes. If  a computer  was to
  45. come with high security, the same  computer-iliterate  sysadmin  would  hardly
  46. ever bother to open it.  Niether would  (s)he  ever  figure out  how to export
  47. directories  to clients. Or how to allow  users  to  rsh  from one  client  to
  48. another  without a password. Or why ping won't  run after cd /usr/etc (about .
  49. in $PATH). 
  50.  
  51. Of course, closed, "secure" system is easier to manage. But most computers are
  52. bought for users,  not  for managers  :) And I  bet  that there are many sites
  53. where users would  rather have insecure but functional system. After  all,  if
  54. you only have local area  network and just several users \n is probably a good
  55. root password.
  56.  
  57. Having said that I agree that it would be nice if manufacturies gave us some
  58. hints about how to make system more secure if needed (or perhaps even shell
  59. scripts to do the convertion). 
  60.  
  61. Oleg
  62.