COPS and Robbers
                    UN*X System Security



     In the last few years, computer security has received a
great  deal  more attention than it has in the past.  Compu-
terized break-ins and criminal  activity,  once  merely  the
product  of  the imagination of science fiction writers, has
became a fairly common  occurence  in  both  commercial  and
academic  circles.   In this paper, I will go over the prob-
lems that face any multiuser computing system, then  discuss
how  these  problems  apply  to  UNIX[1]  specifically,  and
finally  present  in  detail  a  suite of programs that were
developed in an attempt to address some of the main problems
that  could  be  solved  via  software.  UNIX, although con-
sidered to be a fairly secure operating system  ([Wood  88],
[Duff  89], etc), has the advantage of having many published
works ([Grampp and Morris 84],  [Bishop  83],  etc)  on  the
problems  that  a computing site can have with security, and
in addition, on how a UNIX system administrator  might  make
his/her  system more secure by monitoring various aspects of
his/her UNIX site.  This, combined with  UNIX's  popularity,
make  it  an  ideal target for a software security system to
operate on.

     In this report I am not going to discuss specific  ways
of  breaking  into a given UNIX machine (for a more detailed
description on how to compromise UNIX security,  see  either
[Baldwin88],  [Bishop83],  [Wood & Kochran 86], or [Grampp &
Morris 84]) -- instead, I will concentrate on how to improve
and  strengthen  the  potentially good security of a generic
UNIX system by means of a software toolkit that examines the
weaker  areas  of UNIX that are either traditionally ignored
(due to the time constraints  or  ignorance  of  the  system
administrators) or are simply reoccurring problems that need
to be watched over.  In addition, this report is  not  meant
for  UNIX  neophytes -- although a great deal of proficiency
is not needed to read  this  report  and  use  the  programs
described  herein, a familiarity with basic UNIX features --
the file system and file permission modes for example -- and
commands  such  as awk,grep,sed  as  well  as a working
knowledge of  shell  and  C  programming  are  necessary  to
_________________________
9  [1] Although originally designed and developed by Ken
Thompson and Dennis Ritchie of AT&T, UNIX has grown far
beyond its' original design and now numerous  companies
market their own "flavor" of UNIX.  When I use the term
UNIX in this paper, I don't mean merely AT&T's version,
but  instead  I  mean  the majority of the most popular
varieties, made by developers at Berkely,  Sun,  and  a
host of other manufacturers.  I believe UNIX is still a
trademark of Bell Laboratories.
9


                     February 19, 1991





                           - 2 -


understand the internal  workings  of  the  security  system
described in this paper.

     Although there is no reasonable way that  all  security
problems  can  be solved (at least not with a software solu-
tion) on any arbitrary UNIX system, administrators and  sys-
tem  programs  can  be assisted by a software security tool.
The Computer Oracle Password and Security system (COPS) that
will  be described in this paper is just such a device.  The
COPS system is a collection of programs  and  shell  scripts
that  attempt to address as many of these problems as possi-
ble in an efficient, portable, and above all in  a  reliable
and  safe  way.  The main goal of COPS is one of prevention;
it tries to anticipate and eliminate  security  problems  by
making sure people don't get a chance to compromise security
in the first place.  Alerting the administrators of a poten-
tial  intruder  or  that  a virus has infected the system is
beyond the scope of the present system, although  with  work
with  such  capabilities could be added ([Bauer and Koblentz
88] and [Duff 89].)

     To understand the reason COPS might check any  specific
problem,  a look at computer security problems in general is
in order.  The problems listed below are  not  meant  to  be
inclusive,  but  they  are indicative of the myriad types of
dilemmas  a  typical   computer   multiuser   system   might
encounter:

     1)  Administrators, system  programmers,  and  computer
operators.   The  very  people  that (should) worry the most
about security are sometimes the ones  that  are  the  least
concerned.  Carelessness is one of the main culprits; a mis-
take by a user might cause little or no  problem,  but  when
someone  with no restrictions (or almost none) on their com-
puter activity makes a mistake, a security hole can  result.
"I  can  trust  my users" is a fine statement to make -- but
can you trust your users' friends?  How about the  users  of
computers  that  are networked to yours?  New software, sys-
tems, or procedures can facilitate extra problems; a comput-
ing  staff  is  often  ill  or completely non-trained on new
techniques and software.   Too  often  "RTFM"  is  the  only
training  that  they  will  ever receive.  Programs that are
created for in-house use are often  ill-documented  and  not
debugged  thoroughly,  and  when users other than the author
start to use/abuse the program, problems can result.   Espe-
cially  misunderstood,  even by experienced UNIX system pro-
grammers, is the SUID program or, worse yet, the SUID  shell
script ([Bishop 83].) When a user says that his/her password
was forgotten (or any other account/security  related  prob-
lem),  what  checks  are  made  to verify that the person is
really the owner of that account?  Are users that are  secu-
rity  problems kept track of, so that repeated abuses of the
system will result in punitive action?  Does your site  even
have  a  security  policy?  And of course, the last straw is



                     February 19, 1991





                           - 3 -


that most system administrators simply have too  much  other
work to do than to constantly check the system for potential
security flaws -- let alone to double-check  that  any  work
done  by  other  system programmers has been done correctly.
These are the actions that often get left unsaid and undone.

     A UNIX environment has no special defenses against this
kind  of "attack".  Fortunately, a number of these potential
problems  (unless  catastrophic  in  scope)  are  not   only
correctable,  but are easy to detect with a software toolkit
such as COPS.  Even the most careful UNIX guru will periodi-
cally  make  a  mistake;  COPS  has  been designed to aid in
her/his never ending battle against the forces of darkness.

     2)  Physical security.  This is perhaps the most  frus-
trating of all possible problems because it effects all com-
puter systems and is often the hardest to safeguard against.
Even  if the software is secure, even if the system adminis-
trators are alert to potential problems, what happens  if  a
user  walks  up to the root console and starts typing?  Does
the night janitorial staff let anyone into the machine  room
without  proper  identification?  Who  has access to the key
that opens up the computing center?  Are terminals that  are
logged on left unguarded or unlocked?  Are passwords written
on or near a users terminal or desk?   No  software  in  the
world   can  help  against  human  nature  or  carelessness.
Reiterating to your staff and users  that  terminals  should
not  be  left  alone  or unguarded and that passwords (espe-
cially root) should not be typed in front of unfriendly (and
in this case, _everyone_ is your enemy) eyes would be a good
start.  A simple analogy: since you  would  never  give  the
keys  to  the  company car away, why on earth would you give
away the keys to your computer, which is certainly  worth  a
hell  of  a lot more time and money (although it may not get
as good mileage on the interstate.)   Common  sense  goes  a
long ways to help prevent this kind of risk.

     3)   Authentication.   What  is  authentication?    All
modern computing systems that have capabilities for multiple
users have a means of identifying who is using the  computer
at  any  given time.  A common means of identification is by
using a password; and since the inception of this idea, poor
passwords have been a perennial problem.  People have a ten-
dency to use  their  own  name,  or  their  social  security
number,  or  some  other  common word, name, or phrase for a
password.  The problem then arises when an unauthorized user
wants to access clandestine information, he/she simply tries
one of these simple passwords until a  successful  match  is
found.

     Other  problems  with  authentication?   What  computer
hosts  are  "trusted"  and  allow users to log in from other
machines without any further authentication?  Are  incorrect
login   attempts  kept  and/or  monitored  so  as  to  allow



                     February 19, 1991





                           - 4 -


administrators to keep track of any unusual activity?   What
about  "Trojan  horses" -- programs that can steal passwords
and the privileges that a user owns -- is there a program or
a administrative method that detects a potential 'horse?

     Fortunately UNIX systems again have  some  fairly  good
tools  to  aid in this fight.  Although finding simple pass-
words is indeed a trivial task, forcing the users on a  sys-
tem  to  use  passwords  that  are  harder  to guess is also
trivial, by either modifying the mechanism  that  gets/gives
the  password  to  the  user,  and/or  by  having the system
administrators run a simple password detector  periodically,
and notifying users if their password is deemed too obvious.
The crypt command, although proven  to  be  insecure  for  a
knowledgeable and resourceful attacker ([Reed and Weinberger
84], [Baldwin 86]), does offer an added shield against  most
unauthorized  users.   Logs  can  be kept of incorrect login
attempts, but as with most security measures, to  be  effec-
tive  someone (usually the site administrator) must take the
time to examine the evidence.

     4)  Bugs/Features.  Massive software designs  (such  as
an  operating system) are usually the result of a team or of
teams of developers working together.   It  only  takes  one
programmer to make a mistake, and it will almost always hap-
pen.  "Back doors" that  allow  unauthorized  entrances  are
sometimes  purposefully  coded  in -- for debugging, mainte-
nance, or other reasons.  And there  are  always  unexpected
side effects when thousands of people using the system start
doing strange (stupid?) things.  The best  kind  of  defense
against  this  is to report the problems to the developer as
they are discovered, and if possible, to also report  a  way
to fix the problem.  Unfortunately, in many cases the source
code is needed to make a bug fix,  and  especially  in  non-
academic  areas,  this  is  simply  not available due to the
prohibitive costs involved.  Combining this with the  reluc-
tance of a (usually) commercial developer to admit any prob-
lems with their product, and the end result  is  a  security
hole  that  will not be mended unless some kind of financial
loss or gain is at stake -- for the developer  of  the  pro-
duct, not yours!

     5)  Ignorance.  Users who don't know or care can  be  a
problem  as  well.  Even if someone doesn't care about their
own security, they can  unwittingly  compromise  the  entire
system   --   especially  if  they  are  a  user  with  high
privileges.  Administrators and  system  operators  are  not
immune to this either, but hopefully are better informed, or
at least have access to a means of combating  this  dysfunc-
tion.   It  may  also  be due to apathy, an unwillingness to
learn a new system, a lack of time to  explore  all  of  the
features  of  a  large system, or simply not enough computer
savvy to learn more about a very complex system, and no  one
willing  to teach it to the user.  This problem is much like



                     February 19, 1991





                           - 5 -


illiteracy; it is a never-ending battle that will  never  go
completely  away.  And while a software toolkit such as COPS
can  help  combat  this  problem  by  calling  attention  to
neglected  or  misunderstood critical areas, by far and away
the best weapon against this is education.  An educated user
will simply not make as many mistakes; and while it may seem
impractical to teach _all_ users about (even) the  fundamen-
tals  of  computer  security,  think  of  all  the  time and
resources wasted tracking down the mistakes that keep recur-
ring time and time again.

     6)  Unauthorized permissions or privileges.  Are  users
given _too much_ freedom?  Do new computer accounts have any
default security at all, or are the new  users  expected  to
know  what  to do to protect their programs, data, and other
files.  System  files,  programs,  and  data  are  sometimes
shipped  with  minimal or no protection when gotten straight
from the manufacturer; someone at the installation site must
have  enough  knowledge to "tune" the system to be effective
and safe.  Password, memory, and log files especially should
all be carefully monitored, but unfortunately an experienced
user can often still find out any information they want with
perseverance and a little luck.  This is where a system such
as COPS can really shine.  After a new system is configured,
some  basic  flaws can be uncovered with just a small amount
of effort.  New system problems that  somehow  slip  through
the cracks of the site installers can be caught and modified
before any serious problems result.   The  key  here  is  to
prevent  your system users from getting a denial of computer
service that they need and deserve.  Service could mean any-
thing from CPU time, response time, file space, or any other
commodity that a computer has to offer.

     7)  Crackers/Hackers/Evil twin brothers.  Not  much  is
needed  on this subject, save to say that they are often not
the main problem.  Professional  evil-users  are  a  rarity;
often harmful acts are done by users who "just wanted to see
what would happen" or had no idea of  the  ramifications  of
their acts.  Someone who is truly experienced is very diffi-
cult to stop, and is certainly  outside  the  realm  of  any
software  security  tool  as  discussed in this paper.  For-
tunately,  most  evil-doers  are  fairly  inexperienced  and
ignorant,  and when they make a mistake, a watchful adminis-
trator can deal with a problem before it gets out  of  hand.
Sometimes  they  can even reveal security problems that were
previously undiscovered.   COPS  can  help  here  mostly  by
reducing  an  attacker's options; the less holes to exploit,
the better.

     The COPS system attempts to help protect as many of the
above  items  as possible for a generic UNIX system.  In the
proper UNIX spirit, instead of having a large  program  that
attempts  to solve every possible problem, it is composed of
several small programs that each check one or more potential



                     February 19, 1991





                           - 6 -


UNIX  security  holes.   The  COPS  system uses a variety of
these problems to see if there are any  cracks  in  a  given
UNIX security wall.  These methods correspond to some of the
problems discussed above;  specifically  to  administrators,
system  programmers, and computer operators; authentication;
ignorance;  unauthorized  permissions  or  privileges;   and
finally  crackers/hackers/evil twin brothers (numbers 1,3,5,
and 6.)  It is very difficult, almost a  practical  impossi-
bility  to  give software assistance to problems in physical
security, and finally bugs or features that are present in a
given  UNIX  system  are  possible  to  detect,  but are not
covered in this system (yet).  The design of most of the the
programs  were  at  least described if not outlined from the
following sources:

Aho, Kernighan, and Weinberger 88

Baldwin 87

Fiedler and Hunter 86

Grampp and Morris 84

Wood and Kochran 86


     Of course with all of the problems listed below,  look-
ing  at  the  actual  source  code  of  the  program is very
instructive -- each numbered section lists the corresponding
program that is used to perform the check:

     1)  COPS Checks "vital" system directories  to  see  if
they are world-writable.  Directories listed as critical are
in a configuration file and are initially:

/ /etc /usr

/bin /Mail /usr/spool

/usr/adm /usr/etc /usr/lib

/usr/bin /usr/etc /usr/spool/mail

/usr/spool/uucp /usr/spool/at

     The method COPS uses to detect problems -- read through
a  configuration  file  (dir.chklst)  containing  all of the
potential danger  spots,  and  then  simply  comparing  each
directory  modes with a bit mask to see if it is world writ-
able.  The program that performs this task is dir.chk

     2)  Check "vital" system  files  to  see  if  they  are
world-writable.   Files  listed  as critical are in a confi-
guration file (file.chklst) and are initially:



                     February 19, 1991





                           - 7 -


/.*

/etc/*

/bin/*

/usr/etc/yp*

/usr/lib/crontab /usr/lib/aliases /usr/lib/sendmail


The wildcards are used like in UNIX, so these would  include
(some of the more important files):

/.login /.profile /.cshrc /.crontab /.rhost

/etc/passwd /etc/group /etc/inittab /etc/rc

/etc/rc.local /etc/rc.boot /etc/hosts.equiv /etc/profile

/etc/syslog.conf /etc/export

As well as the executable command files (among others):

sh,csh, and ls.


     Method -- again read through a configuration file list-
ing  all  of the files to be checked, comparing each in turn
with a write mask.  The program that performs this  task  is
file.chk

     3)  Check "vital" system  files  to  see  if  they  are
world-readable,  plus  check  for  a NFS file system with no
restriction.  These critical files are:

/dev/kmem /dev/mem

All file systems found in /etc/fstab

Plus a small number of user selectable  files  --  initially
set to include /.netrc, /usr/adm/sulog, and /etc/btmp.

Method -- checking each in turn  against  a  read  mask  for
their  read  status.   The  file  system names are read from
/etc/fstab, the selectable files are  kept  in  a  variable.
The program that performs this task is dev.chk

     4)  Check all files in system for SUID status,  notify-
ing the COPS user of any changes in SUID status.

Method -- Use the "find" command on the root directory (this
must  be  done by root to avoid missing any files unreadable
but still dangerous.) The previous run will  create  a  file



                     February 19, 1991





                           - 8 -


that can be checked against the current run to keep track of
changes in SUID status and any new SUID files.  The  program
that performs this task is suid.chk and was written by Pren-
tiss Riddle.

     5)  Check the /etc/passwd file (and  the  yellow  pages
password   database,  if  applicable)  for  null  passwords,
improper #  of  fields,  non-unique  user-id's,  non-numeric
group id's, blank lines, and non-alphanumeric user-id's.

Method -- Read through password file, flag  any  differences
with  normal password file, as documented in "man 5 passwd".
Fortunately, the syntax of the password file  is  relatively
simple  and  rigid.  The  program that performs this task is
passwd.chk


     6)  Check the /etc/group file  (and  the  yellow  pages
database, if applicable) for groups with passwords, improper
# of fields, duplicate users in  groups,  blank  lines,  and
non-unique group-id's.

Method -- Read through group file, flag any differences with
normal  group  file  as documented in "man 5 group".  Again,
the syntax of this file is fairly simple.  The program  that
performs this task is group.chk

     7)  Check passwords of users on system.

Method -- using  the  stock  "crypt"  command,  compare  the
encrypted password found in the /etc/passwd file against the
following (encrypted) guesses:

The login id (uid), information in the gecos field, and  all
single letter passwords.

The program that performs this  task  is  pass.chk  and  was
written  by  Craig  Leres  and  was modified by Seth Alford,
Roger Southwick, Steve Dum, and Rick Lindsley.

     8)  Check the root path,  umask,  and  if  root  is  in
/etc/ftpuser.

Method -- look inside the /.profile  and  /.cshrc  files  to
ensure  that  all  of  the  directories listed are not world
writable, that "." isn't anywhere in the path, and that  the
umask  is  not set to create world writable files.  The pro-
gram that performs this task is root.chk

     9)  Examine the commands in  /etc/rc*  to  ensure  that
none of the files or paths used are world-writable.

Method -- grep through the files  and  examine  any  strings
that  start  with  "/"  for  writability.   The program that



                     February 19, 1991





                           - 9 -


performs this task is rc.chk

     10)  Examine the commands in /usr/lib/crontab to ensure
that none of the files or paths used are world-writable.

Method -- grep through the  crontab  file  and  examine  any
strings  after field five (first five are not files, but how
crontab is to be run) that start with "/"  for  writability.
The  program  that performs this task is cron.chk 11)  Check
all of the user home directories  to  ensure  they  are  not
world writable.

Method -- get all of the home directories using  the  system
call  getpwent()  and  then  for every home directory found,
check the write permissions of of the home directory against
a bit mask.  The program that performs this task is home.chk
and it was written by John Owens.

     12) Check important user files in  user's  home  direc-
tories  to  ensure  they  are not world writable.  The files
checked (all in the individual users'  home  directory,  all
with the prefix "."):

rhost profile login cshrc kshrc tcshr crhost

netrc forward dbxinit distfile exrc emacsrc

Method -- using the same system call as #10, determine  user
home  directory.   Then  simply check all of the above files
against a bit mask.  The program that performs this task  is
user.chk

     13) Given a goal to compromise, such as user root,  and
a list of user and group id's that can be used in an attempt
to achieve the goal, this security tool will search  through
the  system until it verifies that the goal is compromisible
or not.  The program that performs this tricky task is  part
of the U-Kuang (rhymes with "twang") system.  Robert Baldwin
was kind enough to allow me to include this security checker
(a fine security machine in it's own right) within this dis-
tribution.  For more information on this  fascinating  secu-
rity  checker,  see  kuang.man.ms  and [Baldwin 87].  I have
rewritten it in Bourne shell (it was in C-Shell) for further
portability.

     None of programs listed above certain cover all of  the
possible  areas  that can harm a system, but if run together
they can aid an overworked administrator to locate  some  of
the  potential  trouble spots.  The COPS system is not meant
to be a panacea against  all  UNIX  security  woes,  but  an
administrator who examines the security toolbox programs and
this research paper might reduce the danger  of  their  UNIX
system being compromised -- and that's all any security tool
can ever hope to do.  The COPS system could never replace  a



                     February 19, 1991





                           - 10 -


vigilant  administration  staffed with knowledgeable people,
but hopefully, as administrators look into the package, more
comprehensive  programs  will come into being, covering more
of the problems that will continue as the latest versions of
UNIX continue to grow.

     Design Notes:

     The programs that are described here were  designed  to
address the problems discussed above, but still be usable on
as many UNIX "flavors" as possible.   Speed  was  sacrificed
for  simplicity/portability;  hopefully  the tools here will
either be replaced or modified, as by no means are they  the
final  word  or solution to _any_ of these problems; indeed,
it is my hope that  after  other  programmers/administrators
see  this  report,  they will create newer, better, and more
general tools that can be re-distributed periodically.  None
of the programs need to be run by root to be effective, with
the exception of the SUID checker (to ensure that all  files
are  checked.) Some of the tools were written by myself, the
others were written by other programmers on the network  and
(with their permission) presented here.  All of the programs
in this report are in the public domain, with the  exception
of Robert Baldwin's U-Kuang system; they all exist solely to
be used and modified to fit your needs.   If  they  are  re-
distributed,  please keep them in their original form unless
it is clearly stated that they were modified.  Any  improve-
ments (that might not be too hard :-), suggestions, or other
security programs that you would like  to  see  get  further
distribution can be sent to:

     [email protected]

     (That's me)

     or

     [email protected]

     (Dr. Eugene Spafford)

     Note that the COPS system is still in an infancy  stage
--  although it has been tested on a variety of computers at
Purdue, it has not undergone any serious trials.

     Enhancements I envision include:

i) Improved speed and portability without sacrificing  func-
tionality (pretty obvious, I guess....)

ii) A level of severity assigned to each  warning;  anything
that  could  compromise root instantly (root having no pass-
word, for example) might have a level 0 priority, while sim-
ply  having a user with a writable home directory might only



                     February 19, 1991





                           - 11 -


be level 3.  This way the system could be run at  a  certain
threshold  level, or simply have the set of warnings priori-
tized for a less sophisticated administrator.

iii) Better handling of SUID programs.  The current  program
needs  more  work  to be done on it to be run effectively by
most people; many will not be willing to put the time needed
to  go  through  the list of SUID files by hand to decide if
they are needed or not.  Perhaps also an alarm  would  sound
if a shell script is SUID; doubly so if root owned.

iv) A CRC checker that would check a file  system  (possibly
just  the  most  important  programs  (such as this :-)) and
report if any of the executable files were changed -- possi-
bly signalling a viral infection.

v) The eradication of any design flaws or coding errors that
are in the COPS system.

     The main purpose of creating the COPS system  was  two-
fold;  the first was to foster an understanding of the secu-
rity problems common to most UNIX systems,  and  the  second
was  to  try  to  create and apply software tools that, when
run, will inform system administrators of potential problems
present in their system.  No attempt is made by the tools to
correct any problems because a potential security problem at
one  site  may  be  standard policy/practice at another.  An
emphasis on furthering education and knowledge about UNIX in
general is the key to good security practices, not following
blindly what an unintelligent tool might say.

     Some of the advantages to using a system such  as  COPS
are:

i)  Nearly  Continuous  monitoring  of  traditional  problem
areas.

ii) A new system can be checked before being put  into  pro-
duction.

iii) New or inexperienced administrators can not  only  stop
some  of  their  problems in security they may have, but can
also raise their consciousness about the potential for secu-
rity dilemmas.

     And a couple of disadvantages:

i) An administrator could get a false sense of security from
running  these  programs.  Caveat emptor (ok, they are free,
but still beware.)

ii) A specific path to the elimination of the problem is not
presented.   This  could  also be construed as an advantage,
when considering the third point.



                     February 19, 1991





                           - 12 -


iii) Badguys can get these tools.  You know -- the guys with
black hats.  What happens when they get a copy of this pack-
age?  With any sensitive subject like security, knowledge is
zealously   guarded.    People   are  afraid  that  absolute
knowledge corrupts -- who knows, they may be right.   But  I
staunchly  stand by the tree of knowledge.  Let the bad guys
taste the fruit, and they may see the light,  so  to  speak.
In  addition,  the  system  does  not say how to exploit the
hole, just that it exists.

     Results of Running COPS:

     Not surprisingly, the results when COPS was run  varied
significantly  depending  on what system and site it was run
on.  Here at Purdue, it was run on a Sequent  Symmetry  run-
ning DYNIX 3.0.12, on a pair of Suns (a 3/280 and 3/50) run-
ning UNIX 4.2 release 3.4, a  VAX  11/780  running  4.3  BSD
UNIX,  a  VAX  8600  running  Ultrix 2.2, and finally a NeXT
machine running their 0.9 O/S version of UNIX.  The  results
of  the  COPS  system showed a reasonable amount of security
concern on all of the machines; the  faculty  only  machines
showed  the  weakest security, followed by the machines used
by the graduate  students,  and  finally  the  undergraduate
machines  had  the  strongest  security  (our administrators
_know_ that  you  can't  trust  those  (us?)  young  folks.)
Whether  this was showing that Purdue has a good administra-
tion, or that the UNIX vendors have a fairly good  grasp  on
potential  security problems, or if it was merely showcasing
the shortcomings of this system wasn't clear to me from  the
results.

     The security results probably will  vary  significantly
from  machine  to  machine  --  this is not a fault of UNIX;
merely having the same machine and software  does  not  mean
that  two  sites will not have completely different security
concerns.  In addition, different vendors and administrators
have  significantly varying opinions on how a machine should
be set up.  There is no fundamental reason  why  any  system
cannot  pass  all  or nearly all of these tests, but what is
standard policy at one sites may be an unthinkable  risk  at
another,  depending  upon the nature of the work being done,
the information stored on the computer, and the users of the
system.

     When I first started researching this report, I thought
it  would  be  a  fairly  easy  task.  Go to a few computing
sites, read some theoretical papers, gather all the programs
everyone  had written, and write a brief summary paper.  But
what I found was an tremendous  lack  of  communication  and
concerted  effort towards the subject of security.  AT&T had
written a couple of programs ([Kaplilow and Cherepov 88], as
had   Hewlett   Packard   ([Spence   89]),   but  they  were
proprietary.  I heard rumors that the government was  either
working on or had such a security system, but they certainly



                     February 19, 1991





                           - 13 -


weren't going to give it to me.  The  one  book  devoted  to
UNIX security ([Kochran and Wood 86]) was good, but the pro-
grams that they presented were not expansive enough for what
I  had  in  mind,  plus the fact that they had written their
programs mostly based on System V.  And  while  most  system
administrators  I  talked  to  had  written at least a shell
script or two that performed a  minor  security  task  (SUID
programs seemed the most popular), no one seemed to exchange
ideas or any their problems with  other  sites  --  possibly
afraid  that the admission of a weakness in their site might
be an invitation to disaster.  There is an  excellent  secu-
rity  discussion  group on the network ([Various Authors 84-
]), from which I received some excellent ideas for this pro-
ject, but it is very restrictive to whom it allows to parti-
cipate.  I hope that with the release of this security  sys-
tem it will not only help stamp out problems with UNIX secu-
rity, but would encourage people  to  exchange  ideas,  pro-
grams,  problems  and solutions to the computer community at
large.

Dan Farmer September 29, 1989

     Acknowledgements: I would like to thank Eugene Spafford
for  his  invaluable  help in the researching, planning, and
development of this project.  Without the writings and  pro-
grams created by Robert Morris, Matt Bishop, and other capa-
ble UNIX programmers, this project could never  have  gotten
off  the  ground.  Thanks also go to Brian Kernighan, Dennis
Ritchie, Donald Knuth, and Ken Thompson, for  such  inspira-
tional  computer  work.   And of course without Peg, none of
this would have come into being.  Thanks  again  to  all  of
you.

























                     February 19, 1991





                           - 14 -


                        BIBLIOGRAPHY


_, UNIX Programmers Manual, 4.2 Berkeley Software  Distribu-
tion,  Computer  Science  Division, Department of Electrical
Engineering and Computer Science University  of  California,
Berkeley, CA, August 1983.

_, DYNIX(R) V3.0.12 System Manuals,  Sequent  Computer  Sys-
tems, Inc., 1984.

Aho, Alfred V., Brian W. Kernighan, and Peter J. Weinberger,
The AWK Programming Language, Addison-Wesley Publishing Com-
pany, 1988.

Authors, Various, UNIX Security Mailing  List/Security  Dig-
est, December 1984 -.

Baldwin,  Robert  W.,  Crypt  Breakers  Workbench,   Usenet,
October 1986.

Baldwin, Robert W., Rule Based Analysis  of  Computer  Secu-
rity, Massachusetts Institute of Technology, June 1987.

Bauer, David S. and Michael E. Koblentz, NIDX - A  Real-Time
Intrusion Detection Expert System, Proceedings of the Summer
1988 USENIX Conference, Summer, 1988.

Bishop, Matt, Security Problems with the UNIX Operating Sys-
tem,  Department  of  Computer  Sciences, Purdue University,
January 31, 1983.

Bishop, Matt, How to Write a Setuid Program, April 18, 1985.

Denning, Dorothy, Cryptography and Data  Security,  Addison-
Wesley Publishing Company, Inc, 1983.

Duff, Tom, Viral Attacks On UNIX System  Security,  Proceed-
ings of the Winter 1988 USENIX Conference, Winter, 1988.

Fiedler, David and Bruce Hunter, UNIX System Administration,
Hayden Book Company, 1986.

Grampp, F. T. and R. H. Morris, "UNIX Operating System Secu-
rity,"  AT&T  Bell  Laboratories  Technical Journal, October
1984.

Kaplilow, Sharon A. and Mikhail Cherepov, "Quest -- A  Secu-
rity  Auditing Tool," AT&T Bell Laboratories Technical Jour-
nal, AT&T  Bell  Laboratories  Technical  Journal,  May/June
1988.

Morris, Robert and Ken Thompson, "Password Security : A Case
History," Communications of the ACM, November 1979.



                     February 19, 1991





                           - 15 -


Reed, Brian, "Reflections on Some Recent Widespread Computer
Break-ins,"  Communications  of the ACM, vol. Vol 30, No. 2,
February 1987.

Reed, J.A. and P.J. Weinberger, File Security and  the  UNIX
System  Crypt Command, Vol 63, No. 8, AT&T Bell Laboratories
Technical Journal, October 1984.

Smith, Kirk, Tales of  the  Damned,  UNIX  Review,  February
1988.

Spafford, Eugene H., The Internet Worm Program: An Analysis,
Purdue Technical Report CSD-TR-823, Nov 28, 1988.

Spafford, Eugene H., 1989.  Private Communications

Bruce Spence, spy: A  UNIX  File  System  Security  Monitor,
Workshop  Proceedings  of  the  Large  Installation  Systems
Administration III, September, 1988.

Stoll, Clifford, Stalking the Wily Hacker, Volume 31, Number
5, Communications of the ACM, May 1988.

Thompson, Ken, Reflections on  Trusting  Trust,  Volume  27,
Number 8, Communications of the ACM, August 1984.

Wood, Patrick and Stephen  Kochran,  UNIX  System  Security,
Hayden Books, 1986.

Wood, Patrick, A Loss of Innocence,  UNIX  Review,  February
1988.