Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!csn!cherokee!newsat!jbw From: jbw@maverick.uswest.com (Joe Wells) Newsgroups: comp.admin.policy Subject: Re: SUSPEND SYSOPS, NOT STUDENTS Message-ID: Date: 21 Jun 91 03:03:05 GMT References: <20740@slice.ooc.uva.nl> <1991Jun17.164943.8153@bellcore.bellcore.com> Sender: news@cherokee.uswest.com (Telegraph Row) Organization: /home/zeb1/jbw/.organization Lines: 55 In-Reply-To: jona@iscp.Bellcore.COM's message of 17 Jun 91 16: 49:43 GMT Nntp-Posting-Host: maverick.uswest.com In article <1991Jun17.164943.8153@bellcore.bellcore.com> jona@iscp.Bellcore.COM (Jon Alperin) writes: In article , ckd@eff.org (Christopher Davis) writes: |> He runs COPS on the system (say, without the PW guesser, because |> that takes too damned long). He finds that /var/spool is |> world-writable. He reports this to the sysadmins, who fix it |> (hopefully ;-). Um, why not just ask the system admins to insure that there are no world-writable file systems...that's there job, and not his to go snooping around. Because the sysadmins in question are incompetent and/or lazy, and Mr. Foo would like to encourage the sysadmins to enhance the security of the files he is keeping on the system. Besides, the orignal poster referenced copying /etc/passwd to another system, cracking the password, logging in as that user, and then sending the user mail from their own account. This example is not even close... This paragraph is missing the point; Chris is explaining why it is not a bad idea to inspect the system for security holes. He is not attempting to justify mailing /etc/passwd (with encrypted passwords) to an outside party. |> Perhaps the best way to respect the privacy and security of others |> is to make sure that privacy and security is better maintained. Yes, but breaking security is not the right way to insure that _privacy_ is maintained. If you want to break into your own account, be my guest. Just don't ever screw with someone elses for the simple reason of _looking_ for security holes unless that is what your were specifically hired to do. Mr. Foo was not breaking security. Knowing about security holes is not the same as using them. Knowing someone has left the payroll (in cash) lying on their desk is not the same as taking it. It is especially important to understand that COPS does not do anything unauthorized (except when checking passwords against a dictionary) in finding the security holes. It is mostly just using the Unix stat system call. If the user were unauthorized to use this system call, then it would fail returning no information. (On Unix you do this by putting the file to be kept completely private inside a closed directory.) (BTW, I am speaking from personal experience. I know the incident to which Chris Davis is referring. We were there together, we watched it happen. I was (still am) authorized as root on the machine in question, although my responsibilities were not (in theory, if not in practice) system administration.) -- Joe Wells