
	COPS

	Dan Farmer
	Purdue University
	January 31, 1989

	Adapted to Apollo SR10.1
	Mark C. DiVecchio
	Silogic Systems
	August 15, 1990
	619-549-9841


   Welcome! You now hold in your hands (terminal?) a collection of
security tools that are designed specifically to aid the typical UNIX
systems administrator, programmer, operator, or consultant in the oft
neglected area of computer security. 

   The package, which will be henceforth be referred to as COPS
(Computer Oracle and Password System), can be broken down into three key
parts.  The first is the actual set of programs that attempt to automate
security checks that are often performed manually (or perhaps with self
written short shell scripts or programs) by a systems administrator. 
The second part is the documentation, which details how to set up,
operate, and to interpret any results given by the programs.  Finally,
COPS is an evolving beast.  It includes a list of possible extensions
that might appear in future releases, as well as pointers to other works
in UNIX security that could not be included at this time, due to space
or other restrictions. 

   This document contains six sections:

      1) What is COPS?
      2) What COPS is _not_
      3) How to Configure/Install COPS
      4) Running COPS for the 1st Time
      5) Continued Use of COPS
      6) Disclaimer and End Notes


1) What is COPS?
-----------------

   COPS is a collection of about a dozen programs that each attempt to
tackle a different problem area of UNIX security.  Among the areas
checked are file, directory, and device permissions/modes, passwords,
contents of password and group files, the contents of /etc/rc && cron
files, changes in SUID status, the writability of users home directories
and startup files (.profile, .cshrc, etc), and a few others as well.  It
also includes the Kuang expert system, written by Bob Baldwin, that
takes a set of rules and tries to determine if your system can be
compromised.  For a more complete list of all of the checks, look at the
file "release.notes" or "cops.report."

   All of the programs merely warn the user of a potential problem --
COPS DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL
PROBLEMS IT FINDS! COPS either mails or creates a file (user selectable)
of any of the problems it finds while running on your system.  And
because COPS does not correct potential hazards it finds, it does _not_
have to be run by a privileged account (i.e.  root or whomever.) The
only security check that should be run by root to get maximum results is
the SUID checker; although it can be run as an unprivileged user, to
find all the SUID files in a system, it should be run as root. 

   The programs are mostly written in Bourne shell (using awk, sed,
grep, etc.  as well) for (hopefully) maximum portability.  A few are
written in C for speed (most notably the Kuang expert system and for
implementing fast user home directory searching), but the entire system
should run on most BSD and System V machines with a minimum of tweaking. 

2) What COPS is _not_
----------------------

   COPS merely provides a method of checking for common procedural
errors.  It is not meant to be used as a replacement for common sense or
user/ operator/administrative alertness! Think of it as an aid, a first
line of defense -- not as an impenetrable shield against security woes. 
An experienced wrong-doer could easily circumnavigate _any_ protection
that COPS can give.  However, COPS _can_ aid a system in protecting its
users from (their own?) ignorance, carelessness, and the occasional
malcontent user. 

   Once again, COPS does not correct any errors found.  There are
several reasons for this; first and foremost, computer security is a
slippery beast.  What is a major breach in security at one site may be a
standard policy of openness at another site.  Additionally, in order to
correct all problems it finds, it would have to be run as a privileged
user; and I'm not going to go into the myriad problems of running SUID
shell scripts (See the bibliography at the end of the technical report
"cops.report" for pointer to a good paper on this subject by Matt
Bishop.)

   At this time, COPS does not attempt to detect bugs or features (such
as infamous ftpd, fingerd, etc) that may cause security problems. 
Although this may change in future versions, the current line of
reasoning to avoid general publication of programs such as these is that
all the problems that COPS detects can be repaired on any system it runs
on.  However, many bugs can be readily repaired only be having source
code (and possibly a good vendor to repair it), and many sites would
have serious troubles if they suddenly discovered unrepairable problems
that could compromise their livelihood.  It is possible that a more
controlled release may come out in the future to address such problems
(but don't mail to me about getting them -- unless you want to help
write them! :-))

3) How to Configure/Install COPS
---------------------------------

  System V users, other Non-BSD systems, or sites with commands in
strange places -- you may have to run a shell script called "reconfig"
to change the pathnames of the executable programs called when using
COPS.  If your system does not use the paths listed in the shell
scripts, try running "reconfig".  This will reconfigure the pathnames
used by COPS to your system; COPS should run fine then, if it can find
all of the commands (reconfig should tell you if it cannot.) If trouble
persists, you will have to change the paths to your executable files
(awk, sed, etc) by hand.  A drag, I know.  This all may change without
notice, anyway. 

4) Running COPS for the 1st Time
---------------------------------

   Since most of COPS was written and tested mostly on just a few
machines (at least compared to the total number out there!), you may
have significant differences that were not anticipated -- unfortunately,
or fortunately, UNIX is not quite standardized yet. 

   COPS is run by simply typing "cops".  "cops" is a Bourne shell script
that runs each of the smaller programs, accumulates the output, and then
mails or stores any results.  "suid.chk", since it can take a long, long
time to run, is the only "standalone" program in the COPS package; look
at suid.man for more information. 

   To run COPS for the first time, I suggest doing the following:

   -- Look at the disclaimer, file "disclaimer".  Don't sue me.
      Actually, this holds for all the times you use COPS (1/4 :-))
   -- Type "make" to create the formatted manual pages, to compile the
      C programs,  and to make the shell programs executable.
   -- Read the technical report to understand what COPS is doing and
      what is going on -- "cops.report".  This gives a look at the
      philosophies, design notes, and finally a general outlay of the
      COPS system and UNIX security.
   -- Next, change lines 36 and 37 in the "cops" shell file from:
        SECURE=/usr/foo/bar
        SECURE_USERS="foo@bar.edu"
      SECURE should be the same directory as the directory that contains
      the cops programs, and SECURE_USERS should be your own login id, or
      to whomever you designate as the recipient of the output (your enemy?)
   -- Set "MMAIL=NO" in the "cops" shell file.  This will prevent
      a large mail file from choking the mailer.  All of the output will be
      put into a file called "report.node.id.$$", where $$ is the process
      number that cops had while running.
   -- Look at the directory and file configuration files, "dir.chklst"
      and "file.chklst".  They contain critical files that COPS checks
      for world writability.  Add or delete whatever files/directories
      you wish; if a file doesn't exist, COPS will effectively ignore it.
      (If you don't know or are uncertain what files/directories are
      important, what is given there is a good set to start with on most
      systems.
   -- You may wish to comment out the password checker (line 72 in the
      "cops" shell file).  Although this is not necessary, it will speed
      up the package if you wish for immediate gratification.

  You should be ready to roll.  COPS is run by simply typing "cops" (you
may wish to put in the background....) If you followed my advice and set
"MMAIL=NO" in the "cops" shell file, after COPS is finished, there will
be a report file created "report.$$" that lists the time and machine it
was created on.  Otherwise, COPS mails the report to the user listed on
the line 'SECURE_USERS="foo@bar.edu"'.  There is a file "warnings",
which contains most of the warning messages COPS uses, as well as a
brief explanation of how the message might pertain to your system as
well as how to "fix" any problem. 

   NOTE: Change the shell script "cops" to reflect who you want the
output sent to and where the location of the program is BEFORE running
the program. 


5) Continued Use of COPS
-------------------------

   Once you are satisfied that COPS indeed does something useful
(hopefully this will occur :-)), a good way to use it is to run it on at
least a semi-regular basis.  Even if it doesn't find any problems
immediately, the types of problems and holes it can detect are of the
sort that can pop up at any given time.  One way of running COPS might
be to run it as an "at" job or by cron. 

   I highly advise that whatever directory COPS is placed in is to be
readable, writable, and executable only by the owner (typing "chmod 700
/usr/foo/bar" or whatever the name is will do this) of the directory. 
This is to prevent prying eyes from seeing any security problems your
site may have.  Even if you don't think of them as important, someone
else might come around and change your mind.  Since COPS is fairly
configurable, an intruder could easily change the paths and files that
COPS checks for, hence making it fairly worthless.  Again, this comes
back to the point that COPS is only a tool -- don't put down your
defensive shields merely because COPS says "all clear".  If this sounds
paranoid, it is! Security people are traditionally paranoid, for a
reason....  In any case, it is probably not a good idea to advertise any
(even) potential weaknesses. 

   After running COPS, if any warnings are given that compromise any
individual users accounts (such as world writable .profiles, home
directories, guessed passwords, etc.), and the warnings are not
corrected immediately (or you are not sure whether or not it is worth
hassling the user to change it), try this:

   Edit the file "init_kuang", and add the compromised user(s) uids and
groups in their respective target lines (below lines 21 and 27,
respectively), and run kuang again to see if the users can compromise
the entire system.  You may change your mind about not thinking they are
a problem! In addition, kuang does not have to have "root" as a target
(the last line).  Try putting in system administrators or other powerful
figures to see if they are in danger as well. 

6) Disclaimer and End Notes
----------------------------

   COPS is meant to be a tool to aid in the tightening of security, not
as a weapon to be used by an enemy to find security flaws in a system. 
It may be argued that allowing anyone to have access to such a tool may
be dangerous.  But hopefully the overall benefit for systems that use
this package will outweigh any negative impact.  To me it is akin to a
law enforcement problem -- that although telling the public how to break
into a house may foster a slight rise in break-in attempts, the overall
rise in public awareness on how to defend themselves would actually
result in a drop in break-ins.  The crackers with black hats already
know how to crush system defenses and have similar tools, I'm sure. 
It's time we fought back. 

  COPS is not the final answer to anyone's security woes.  You can use
the system as long as you realize that COPS has no warranty, implied or
otherwise, and that any problems that you may have with it are not my or
any of the other authors fault.  I will certainly attempt to help you
solve them, if I am able, but please don't try to sue me or anything... 
Let's all make COPS a collective effort that helps people, ok? If you
have ideas for additional programs, or a better implementation of any of
the programs here, I would be very interested in seeing them.  COPS was
the work of a LOT of people, both in writing code and in the testing
phase (thanks beta testers!).  For a complete list of contributors, look
at the file "XTRA_CREDIT". 

   So good luck, and I hope you find COPS useful as we plunge into UNIX
of the 1990's. 

# include "disclaimer.h"

-------------------- Cut here for disclaimer -------------------------

/***********************************************************************
* Copyright 1989, 1990 by Purdue University and Dan Farmer.  All rights
* reserved.  Some individual files may be covered by other copyrights.
* 
* This material was written and compiled by Dan Farmer while at Purdue
* University in 1989 and 1990, under the direction and sponsorship of
* Professor Gene Spafford.  Other material was contributed as noted
* elsewhere.
* Redistribution and use in source and binary forms are permitted
* provided that this entire copyright notice is duplicated in all such
* copies, and that any documentation, announcements, and other
* materials related to such distribution and use acknowledge that the
* software was developed at Purdue University, W. Lafayette, IN.  No
* charge, other than an "at-cost" distribution fee, may be charged for
* copies, derivations, or distributions of this material without the
* express written consent of the copyright holders.  Neither the
* name of the University, the name of the author, nor the name of this
* project's sponsor may  be used to endorse or promote products
* derived from this material without specific prior written permission.
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
* WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
* MERCHANTIBILITY AND FITNESS FOR ANY PARTICULAR PURPOSE.
************************************************************************/
---------------------- End disclaimer -------------------------------
