Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!world!eff!ckd From: ckd@eff.org (Christopher Davis) Newsgroups: comp.admin.policy Subject: Re: SUSPEND SYSOPS, NOT STUDENTS Message-ID: Date: 17 Jun 91 19:23:11 GMT References: <20740@slice.ooc.uva.nl> <1991Jun17.164943.8153@bellcore.bellcore.com> Sender: ckd@eff.org (Christopher Davis) Organization: The Electronic Frontier Foundation Lines: 70 In-Reply-To: jona@iscp.Bellcore.COM's message of Mon, 17 Jun 91 16:49:43 GMT Jon> == Jon Alperin ckd> == me ckd> Mr. Edward Foo has an account on vax99.big-u.edu. He keeps some ckd> things there, that (while not horrendous top secret information) ckd> he'd rather keep out of the way of J. Random Luser. ckd> He runs COPS on the system (say, without the PW guesser, because ckd> that takes too damned long). He finds that /var/spool is ckd> world-writable. He reports this to the sysadmins, who fix it ckd> (hopefully ;-). Jon> Um, why not just ask the system admins to insure that there are Jon> no world-writable file systems...that's there job, and not his to Jon> go snooping around. Well, if that's their job, then there shouldn't be any world-writable critical directories, no? And the best way to "ask the system admins to insure there are no world-writable file systems [sic]" is probably to point out any that ARE, so they can get fixed. Jon> Besides, the orignal poster referenced copying /etc/passwd to Jon> another system, cracking the password, logging in as that user, Jon> and then sending the user mail from their own account. This Jon> example is not even close... No, it's not. But it's being treated as the same level of incident, in some places. Jon> [...] [B]reaking security is not the right way to insure that Jon> _privacy_ is maintained. If you want to break into your own Jon> account, be my guest. Just don't ever screw with someone elses Jon> for the simple reason of _looking_ for security holes unless that Jon> is what your were specifically hired to do. We seem to have a divergence of theory here. I feel that it is possible to know about, detect, and fix security holes without necessarily exploiting them in any way, or damaging anything in any way. Example: if I detected the /var/spool world-writable problem on a machine I had an account (but not sysadm) on, I would have several choices, including: (1) keep quiet and hope nobody uses it before it gets fixed; (2) exploit it, become root, and fix the problem myself; (3) exploit it, become root, and just go my merry cracker way; (4) report it to the appropriate people and let THEM fix it. My view is that number 4 is the only appropriate response. EVEN THOUGH that hole would give me the power to become root, and EVEN THOUGH I would "only" use root to fix the problem, THAT IS NOT MY JOB ON THAT SYSTEM. However, *reporting* any holes I find (or can find, as a "normal user") is my job, as part of the cooperating "membership" of the system. Security is everyone's responsibility; users are often told "keep your password safe" and "use a good password." Why should their involvement stop there? I would rather have one technically-competent and involved user who feels she has a stake in keeping the system running and secure than 100 people who feel "in the dark" and treat me as "that evil security ogre who keeps harping on password choices." -- Christopher Davis - System Manager & Postmaster, Electronic Frontier Foundation <{uunet,bu.edu,...}!world!eff!ckd> NeXT: 155 Second Street, Cambridge, MA 02141 - +1 617 864 0665 - FAX: +1 617 864 0866 "Internet mail headers are not unlike giblets." - Paul Vixie