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;  anythingthat  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  certainthreshold  level, or simply have the set of warnings priori-tized for a less sophisticated administrator.iii) Better handling of SUID programs.  The current  programneeds  more  work  to be done on it to be run effectively bymost people; many will not be willing to put the time neededto  go  through  the list of SUID files by hand to decide ifthey are needed or not.  Perhaps also an alarm  would  soundif a shell script is SUID; doubly so if root owned.iv) A CRC checker that would check a file  system  (possiblyjust  the  most  important  programs  (such as this :-)) andreport if any of the executable files were changed -- possi-bly signalling a viral infection.v) The eradication of any design flaws or coding errors thatare 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  secondwas  to  try  to  create and apply software tools that, whenrun, will inform system administrators of potential problemspresent in their system.  No attempt is made by the tools tocorrect any problems because a potential security problem atone  site  may  be  standard policy/practice at another.  Anemphasis on furthering education and knowledge about UNIX ingeneral is the key to good security practices, not followingblindly what an unintelligent tool might say.     Some of the advantages to using a system such  as  COPSare:i)  Nearly  Continuous  monitoring  of  traditional  problemareas.ii) A new system can be checked before being put  into  pro-duction.iii) New or inexperienced administrators can not  only  stopsome  of  their  problems in security they may have, but canalso 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 fromrunning  these  programs.  Caveat emptor (ok, they are free,but still beware.)ii) A specific path to the elimination of the problem is notpresented.   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 withblack hats.  What happens when they get a copy of this pack-age?  With any sensitive subject like security, knowledge iszealously   guarded.    People   are  afraid  that  absoluteknowledge corrupts -- who knows, they may be right.   But  Istaunchly  stand by the tree of knowledge.  Let the bad guystaste the fruit, and they may see the light,  so  to  speak.In  addition,  the  system  does  not say how to exploit thehole, just that it exists.     Results of Running COPS:     Not surprisingly, the results when COPS was run  variedsignificantly  depending  on what system and site it was runon.  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  BSDUNIX,  a  VAX  8600  running  Ultrix 2.2, and finally a NeXTmachine running their 0.9 O/S version of UNIX.  The  resultsof  the  COPS  system showed a reasonable amount of securityconcern on all of the machines; the  faculty  only  machinesshowed  the  weakest security, followed by the machines usedby the graduate  students,  and  finally  the  undergraduatemachines  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  onpotential  security problems, or if it was merely showcasingthe shortcomings of this system wasn't clear to me from  theresults.     The security results probably will  vary  significantlyfrom  machine  to  machine  --  this is not a fault of UNIX;merely having the same machine and software  does  not  meanthat  two  sites will not have completely different securityconcerns.  In addition, different vendors and administratorshave  significantly varying opinions on how a machine shouldbe set up.  There is no fundamental reason  why  any  systemcannot  pass  all  or nearly all of these tests, but what isstandard policy at one sites may be an unthinkable  risk  atanother,  depending  upon the nature of the work being done,the information stored on the computer, and the users of thesystem.     When I first started researching this report, I thoughtit  would  be  a  fairly  easy  task.  Go to a few computingsites, read some theoretical papers, gather all the programseveryone  had written, and write a brief summary paper.  Butwhat I found was an tremendous  lack  of  communication  andconcerted  effort towards the subject of security.  AT&T hadwritten a couple of programs ([Kaplilow and Cherepov 88], ashad   Hewlett   Packard   ([Spence   89]),   but  they  wereproprietary.  I heard rumors that the government was  eitherworking 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  toUNIX security ([Kochran and Wood 86]) was good, but the pro-grams that they presented were not expansive enough for whatI  had  in  mind,  plus the fact that they had written theirprograms mostly based on System V.  And  while  most  systemadministrators  I  talked  to  had  written at least a shellscript or two that performed a  minor  security  task  (SUIDprograms seemed the most popular), no one seemed to exchangeideas or any their problems with  other  sites  --  possiblyafraid  that the admission of a weakness in their site mightbe 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 atlarge.Dan Farmer September 29, 1989     Acknowledgements: I would like to thank Eugene Spaffordfor  his  invaluable  help in the researching, planning, anddevelopment 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  gottenoff  the  ground.  Thanks also go to Brian Kernighan, DennisRitchie, Donald Knuth, and Ken Thompson, for  such  inspira-tional  computer  work.   And of course without Peg, none ofthis would have come into being.  Thanks  again  to  all  ofyou.                     February 19, 1991                           - 14 -                        BIBLIOGRAPHY_, UNIX Programmers Manual, 4.2 Berkeley Software  Distribu-tion,  Computer  Science  Division, Department of ElectricalEngineering 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-TimeIntrusion Detection Expert System, Proceedings of the Summer1988 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, October1984.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/June1988.Morris, Robert and Ken Thompson, "Password Security : A CaseHistory," Communications of the ACM, November 1979.                     February 19, 1991                           - 15 -Reed, Brian, "Reflections on Some Recent Widespread ComputerBreak-ins,"  Communications  of the ACM, vol. Vol 30, No. 2,February 1987.Reed, J.A. and P.J. Weinberger, File Security and  the  UNIXSystem  Crypt Command, Vol 63, No. 8, AT&T Bell LaboratoriesTechnical Journal, October 1984.Smith, Kirk, Tales of  the  Damned,  UNIX  Review,  February1988.Spafford, Eugene H., The Internet Worm Program: An Analysis,Purdue Technical Report CSD-TR-823, Nov 28, 1988.Spafford, Eugene H., 1989.  Private CommunicationsBruce Spence, spy: A  UNIX  File  System  Security  Monitor,Workshop  Proceedings  of  the  Large  Installation  SystemsAdministration III, September, 1988.Stoll, Clifford, Stalking the Wily Hacker, Volume 31, Number5, 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,  February1988.