home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / security / misc / 2286 < prev    next >
Encoding:
Text File  |  1992-12-15  |  4.1 KB  |  120 lines
  1. Newsgroups: comp.security.misc
  2. Path: sparky!uunet!usc!sdd.hp.com!spool.mu.edu!agate!dog.ee.lbl.gov!news!avalon.nwc.navy.mil!mars!jd
  3. From: jd@mars.nwc.navy.mil (John de la Garrigue)
  4. Subject: Re: Security vs usefulness (was Re: reasons for disable fingerd)
  5. Message-ID: <BzA4Ks.230@avalon.nwc.navy.mil>
  6. Sender: usenet@avalon.nwc.navy.mil (NWC News Admin)
  7. Reply-To: jd@mars.nwc.navy.mil
  8. Organization: Science Applications International Corporation
  9. References: <1ghs93INNl04@iraul1.ira.uka.de>
  10. Date: Tue, 15 Dec 1992 02:36:28 GMT
  11. Lines: 107
  12.  
  13. In article 1ghs93INNl04@iraul1.ira.uka.de, s_titz@ira.uka.de (Olaf Titz) writes:
  14. >In article <WCS.92Dec13203554@rainier.ATT.COM> wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705) writes:
  15. >>
  16. >>The main job of security is to say "NO".  
  17. >>The main job of Unix is to say "Yes".
  18. >
  19. >O.K., you agree in this point: The main job of Unix is to get the
  20. >user's work done.
  21. >The main job of security is to stop the user from getting his work
  22. >done.
  23.  
  24. This is a ludicrous statement.
  25.  
  26. Some of the reasons for implementing security on a computer is to protect the 
  27. information processed and/or stored on it from unauthorized disclosure; protect
  28. the information processed and/or stored on it from unauthorized additions, 
  29. deletions or other changes; and protect the machine from being misused, however
  30. the organization that owns it chooses to define "misuse".
  31.  
  32. >
  33. >=> "Security" as defined such belongs on the crap heap and not in
  34. >computers that are to be USED, imho.
  35.  
  36. Your opinion.  Not everyone else in the world shares it.
  37.  
  38. >
  39. >>The other main job of security is to keep track of who did what to what,
  40. >
  41. >To spy on the users.
  42.  
  43. Lord have mercy!  Paranoia will destray ya!  Has it occured to you that audit trails 
  44. can be used to figure out what brought a system to it's knees and provide clues as
  45. to fixing the problem?
  46.  
  47. >
  48. >>    so that if you decide the system *should* have said no, but didn't,
  49. >>    you know what got stolen.
  50. >
  51. >But then it is too late and you have caught a bug, perhaps, but not
  52. >the intruder, according to your 'security' definition.
  53.  
  54. And isn't this worth knowing?
  55.  
  56. >
  57. >(And, mentioning that word reminds me of the following: The sometimes
  58. >arbitrary redefinition of an otherwise legitimate user as 'intruder'
  59. >makes me at least raise an eyebrow.)
  60.  
  61. And I've seen "legitimate" users do some very strange things that instantly
  62. classify them as intruders.
  63.  
  64. >
  65. >>...
  66. >>to fix if you *know* the identity of the real user, 
  67. >>and that sometimes it's genuinely hard to know who the real user is,
  68. >
  69. >Do you ever know who the 'real' user is...
  70. >
  71. >>especially across a network where you don't control the other end.
  72. >
  73. >....even on your local machine?
  74.  
  75. True.  And sometimes "real/trusted" users do things that look suspicious, and
  76. turn out to be a legitimate action.  This is a problem that security is trying to
  77. address, admittedly with mixed results.
  78.  
  79. >
  80. >>One way to resolve the latter problem is to always trust the user;
  81. >
  82. >That from *you*? ;-)
  83. >
  84. >>another way is to never trust the user; a middle way is to work hard
  85. >>and try to give you some control about how much trust you have.
  86. >>
  87. >>(Then of course, there are bugs and misfeatures, and the relative
  88. >>quantities of these in Unix vs. other OS's is beyond the scope of this note :-)
  89. >
  90.  
  91. <stuff about rogue sys admins deleted - no argument, it *could* happen>
  92.  
  93. >
  94. >>But it is a lot easier to do security, and everything else,
  95. >
  96. >Security, as defined above, means unusability - for this I don't need
  97. >any OS at all. I switch the machine off.
  98.  
  99. Not necessarilly.  You don't have to turn the machine off to have a secure system.
  100. Just make it single user and unconnected in any way from another machine.  This
  101. does not imply unusability, mind you.
  102.  
  103. <more stuff deleted>
  104.  
  105.  
  106. ---
  107.                 __
  108.            /  /   \
  109.           /  /    /
  110.    /     /  /    /
  111.   /_____/  /____/
  112.  
  113. John de la Garrigue                              ||  Phone:  619/546-6192
  114. Site Manager                                     ||  E-mail: jd@c3ot.saic.com
  115. Science Applications International Corp. (SAIC)  ||  
  116.  
  117. My views are not necessarily those of my employer, the US government,
  118. or anyone else for that matter.
  119.  
  120.