🚀 go-pugleaf

In article <1991Jun17.164943.8153@bellcore.bellcore.com> jona@iscp.Bellcore.COM (Jon Alperin) writes:

   In article <CKD.91Jun17111320@eff.org>, 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 <jbw@uswest.com>