Article View: comp.security.misc
Article #888Re: CERT and the Dept. of Justice on keystr
From: Leonard Erickson
Date: Thu, 17 Dec 1992 00:43
Date: Thu, 17 Dec 1992 00:43
41 lines
2770 bytes
2770 bytes
jpe@ee.egr.duke.edu (John P. Eisenmenger) writes: >This borderline legality is comparable to what we as administrators face when >trying to maintain the security of our systems. This is the reason we have to >put such a banner on our systems. Does such a banner give blanket protection >to the administrators? It does not - notice the phrase "In the course of >monitoring individuals improperly using this system, or [...] system >maintenance". This restricts the authority of the administrator, and I would >imagine that if a legal case were to ensue the administrator had better have >a d*mn good log of the evidence that lead to the monitoring. >BTW: I have yet to figure out why I would monitor an individual while doing >system maintenance. Anyone have any examples? I think that part is more aimed at reading *files*. As administrator of the LAN at a company I used to work for, I sometimes had to free up space. Which meant looking for "backup" files, redundant copies of drivers (some folks kept putting copies of drivers in their personal directories, even though the LAN was set up so that the programs would "see" the ones in a public directory as being in any directory). So I'd put out the usual notice that I'd be going thru and nuking the files. Then a day or so later (except in *real* space crunches) I'd run a script to kill the "obvious" stuff. Then I had to page thru all the directories to find the stuff the script wasn't smart enough to handle safely. So I saw a *lot* of files that were "suspicious". I left them alone, mostly. It wasn't my business if someone had his resume (named "resume" :-) in his directory. I did send notes to folks about some things. Like games and GIF files. But that was mostly a "Please move it, we need the space" message. And I've had to "snoop" because someone had files locked open that interfered with a backup or with a system shutdown. -- Leonard Erickson leonard@qiclab.scn.rain.com CIS: [70465,203] 70465.203@compuserve.com FIDO: 1:105/51 Leonard.Erickson@f51.n105.z1.fidonet.org (The CIS & Fido addresses are preferred)
Technical Details
Message-ID:
<1992Dec17.004307.15153@qiclab.scn.rain.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!uwm.edu!ogicse!qiclab!leonardReferences:
<1992Dec11.235142.3072@nntp.hut.fi> <1992Dec12.043113.24232@lambda.msfc.nasa.gov> <jpe.724345261@ee.egr.duke.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!uwm.edu!ogicse!qiclab!leonard From: leonard@qiclab.scn.rain.com (Leonard Erickson) Newsgroups: comp.security.misc Subject: Re: CERT and the Dept. of Justice on keystr Message-ID: <1992Dec17.004307.15153@qiclab.scn.rain.com> Date: 17 Dec 92 00:43:07 GMT Article-I.D.: qiclab.1992Dec17.004307.15153 References: <1992Dec11.235142.3072@nntp.hut.fi> <1992Dec12.043113.24232@lambda.msfc.nasa.gov> <jpe.724345261@ee.egr.duke.edu> Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org Organization: SCN Research/Qic Laboratories of Tigard, Oregon. Lines: 41