home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / security / misc / 2306 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!uwm.edu!ogicse!qiclab!leonard
  2. From: leonard@qiclab.scn.rain.com (Leonard Erickson)
  3. Newsgroups: comp.security.misc
  4. Subject: Re: CERT and the Dept. of Justice on keystr
  5. Message-ID: <1992Dec17.004307.15153@qiclab.scn.rain.com>
  6. Date: 17 Dec 92 00:43:07 GMT
  7. Article-I.D.: qiclab.1992Dec17.004307.15153
  8. References: <1992Dec11.235142.3072@nntp.hut.fi> <1992Dec12.043113.24232@lambda.msfc.nasa.gov> <jpe.724345261@ee.egr.duke.edu>
  9. Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
  10. Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
  11. Lines: 41
  12.  
  13. jpe@ee.egr.duke.edu (John P. Eisenmenger) writes:
  14.  
  15. >This borderline legality is comparable to what we as administrators face when
  16. >trying to maintain the security of our systems.  This is the reason we have to
  17. >put such a banner on our systems.  Does such a banner give blanket protection
  18. >to the administrators?  It does not - notice the phrase "In the course of
  19. >monitoring individuals improperly using this system, or [...] system
  20. >maintenance".  This restricts the authority of the administrator, and I would
  21. >imagine that if a legal case were to ensue the administrator had better have
  22. >a d*mn good log of the evidence that lead to the monitoring.
  23.  
  24. >BTW: I have yet to figure out why I would monitor an individual while doing
  25. >system maintenance.  Anyone have any examples?
  26.  
  27. I think that part is more aimed at reading *files*.
  28.  
  29. As administrator of the LAN at a company I used to work for, I sometimes
  30. had to free up space. Which meant looking for "backup" files, redundant
  31. copies of drivers (some folks kept putting copies of drivers in their
  32. personal directories, even though the LAN was set up so that the programs
  33. would "see" the ones in a public directory as being in any directory).
  34. So I'd put out the usual notice that I'd be going thru and nuking the
  35. files. Then a day or so later (except in *real* space crunches) I'd
  36. run a script to kill the "obvious" stuff. Then I had to page thru all
  37. the directories to find the stuff the script wasn't smart enough to
  38. handle safely.
  39.  
  40. So I saw a *lot* of files that were "suspicious". I left them alone, mostly.
  41. It wasn't my business if someone had his resume (named "resume" :-) in his 
  42. directory. I did send notes to folks about some things. Like games and
  43. GIF files. But that was mostly a "Please move it, we need the space"
  44. message.
  45.  
  46. And I've had to "snoop" because someone had files locked open that
  47. interfered with a backup or with a system shutdown. 
  48.  
  49. -- 
  50. Leonard Erickson              leonard@qiclab.scn.rain.com
  51. CIS: [70465,203]             70465.203@compuserve.com
  52. FIDO:   1:105/51     Leonard.Erickson@f51.n105.z1.fidonet.org
  53. (The CIS & Fido addresses are preferred)
  54.