cops and robbers-unix system security.txt

1000 HOWTOs for various needs [WINDOWS]

     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.