home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / c / cops_104.zip / cops_104 / README.1 < prev    next >
Text File  |  1992-03-10  |  12KB  |  247 lines
  1.  
  2.    Welcome!  You now hold in your hands (terminal?) a collection of
  3. security tools that are designed specifically to aid the typical UNIX
  4. systems administrator, programmer, operator, or consultant in the
  5. oft-neglected area of computer security.
  6.  
  7.    If you're the kind of boy/girl/rock who thinks "man pages are for
  8. weenies, let's type 'make' and run the damn thing," then you might read
  9. one file, "quickstart", for a lightning-fast intro.  Otherwise, reading
  10. this now might prove enlightening.
  11.  
  12.    The package, which will henceforth be referred to as COPS (Computer
  13. Oracle and Password System), can be broken down into three key parts.
  14. The first is the actual set of programs that attempt to automate
  15. security checks that are often performed manually (or perhaps with self-
  16. written short shell scripts or programs) by a systems administrator.
  17. The second part is the documentation, which details how to set up,
  18. operate, and interpret the results of the programs.  It also includes a
  19. paper or two on COPS itself.  Third, COPS is an evolving beast, so it
  20. includes a list of possible extensions that might appear in future
  21. releases.  In addition, it includes some short papers on various topics
  22. in UNIX security and pointers to other works in UNIX security that could
  23. not be included at this time, due to space or other restrictions.
  24.  
  25.    This document contains four sections:
  26.  
  27.       1) What is COPS?
  28.       2) What is COPS _not_?
  29.       3) Installation, Execution, and Continuing Use of COPS
  30.       4) Disclaimer and End Notes
  31.  
  32.  
  33. 1) What is COPS?
  34. -----------------
  35.  
  36.    The heart of COPS is a collection of about a dozen (actually, a few
  37. more, but a dozen sounds so good) programs that each attempt to tackle
  38. a different problem area of UNIX security.  Here is what the programs
  39. currently check, more or less (they might check more, but never less,
  40. actually):
  41.  
  42. o  file, directory, and device permissions/modes.
  43.  
  44. o  poor passwords.
  45.  
  46. o  content, format, and security of password and group files.
  47.  
  48. o  the programs and files run in /etc/rc* and cron(tab) files.
  49.  
  50. o  existance of root-SUID files, their writeability, and whether or not
  51.    they are shell scripts.
  52.  
  53. o  a CRC check against important binaries or key files to report any
  54.    changes therein. 
  55.  
  56. o  writability of users home directories and startup files (.profile,
  57.    .cshrc, etc.) 
  58.  
  59. o  anonymous ftp setup.
  60.  
  61. o  unrestricted tftp, decode alias in sendmail, SUID uudecode problems, 
  62.    hidden shells inside inetd.conf, rexd running in inetd.conf.
  63.  
  64. o  miscellaneous root checks -- current directory in the search path,
  65.    a "+" in /etc/host.equiv, unrestricted NFS mounts, ensuring root is 
  66.    in /etc/ftpusers, etc.
  67.  
  68. o  dates of CERT advisories vs. key files.  This checks the dates that
  69.    various bugs and security holes were reported by CERT against the
  70.    actual date on the file in question.  A positive result doesn't
  71.    always mean that a bug was found, but it is a good indication that
  72.    you should look at the advisory and file for further clues.  A
  73.    negative result, obviously, does not mean that your software has no
  74.    holes, merely that it has been modified in SOME way (perhaps merely
  75.    "touch"'ed) since the advisory was sent out.
  76.  
  77. o  the Kuang expert system.  This takes a set of rules and tries to
  78.    determine if your system can be compromised (for a more complete list 
  79.    of all of the checks, look at the file "release.notes" or
  80.    "cops.report"; for more on Kuang, look at at "kuang.man".)
  81.  
  82.    All of the programs merely warn the user of a potential problem --
  83. COPS DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL
  84. PROBLEMS IT FINDS!  COPS either mails or creates a file (user
  85. selectable) of any of the problems it finds while running on your
  86. system.  Because COPS does not correct potential hazards it finds, it
  87. does _not_ have to be run by a privileged account (i.e. root or
  88. whomever.)  The only security check that should be run by root to get
  89. maximum results is the SUID checker: although it can be run as an
  90. unprivileged user, it should be run as root so that it can find all the
  91. SUID files in a system.  In addition, if key binaries are not
  92. world-readable, only executable, the CRC checking program ("crc.chk")
  93. needs to be run as a privileged user to read the files in question to
  94. get the result.)  Also note that COPS cannot used to probe a host
  95. remotely; all the tests and checks made require a shell that is on the
  96. host being tested.
  97.  
  98.    The programs that make up COPS were originally written primarily in
  99. Bourne shell (using awk, sed, grep, etc.) for (hopefully) maximum
  100. portability, with a few written in C for speed (most notably parts of
  101. the Kuang expert system and the implementation of fast user home
  102. directory searching), but the entire system should run on most BSD and
  103. System V machines with a minimum of tweaking.  In addition, a perl
  104. version is included that, while perhaps not as portable as the shell/C
  105. version, has some advantages.
  106.  
  107.    COPS includes various support programs as well.  The primary one is
  108. CARP (COPS Analysis and Report Program).  CARP is a results interpreter
  109. that is designed to analyze and generate a summary on various COPS reports
  110. from a complete network or set of hosts.
  111.  
  112. 2) What is COPS _not_?
  113. -----------------------
  114.  
  115.    COPS mostly provides a method of checking for common procedural
  116. errors.  It is not meant to be used as a replacement for common sense or
  117. user/operator/administrative alertness!  Think of it as an aid, a first
  118. line of defense, not as an impenetrable shield against security woes.
  119. An experienced wrong-doer could easily circumvent *any* protection that
  120. COPS can give.  However, COPS *can* aid a system in protecting its users
  121. from (their own?) ignorance, carelessness, and the occasional malcontent
  122. user.
  123.  
  124.    Once again, COPS does not correct any errors found.  There are
  125. several reasons for this: first and foremost, computer security is a
  126. slippery beast.  What is a major breach in security at one site may be a
  127. standard policy of openness at another site.  Additionally, in order to
  128. correct all problems it finds, it would have to be run as a privileged
  129. user; I'm not going to go into the myriad problems of running SUID shell
  130. scripts (see the bibliography at the end of the technical report
  131. "cops.report" for pointer to a good paper on this subject by Matt
  132. Bishop; look at the included paper "SU" for pointers on how to write a
  133. SUID program) -- suffice to say it's a bad idea that can give an
  134. attacker privileges equal to whatever account the shell is SUID to.
  135.  
  136. 3) Installation, Execution, and Continuing Use of COPS
  137. -------------------------------------------------------
  138.  
  139.    There are two versions of COPS that can be run.  The original ("COPS
  140. classic"?) needs nothing more than a C compiler and the standard shell
  141. tools that any (or most any) UNIX system should have: awk, sed, grep,
  142. etc.  For information on how to configure and run this version, look at
  143. the file "README.2.sh".  The most important thing to do is to run the
  144. shell program "reconfig" if you have a system V or a non-standard
  145. Berkeley UNIX system -- the paths to the programs that COPS uses are
  146. hard-coded, and this will reconfigure the paths so that COPS can find
  147. these programs.
  148.  
  149.    If you have installed perl on your system (I think it works with perl
  150. versions > 3.18) and would like to try the perl version, look at the
  151. file "README.2.pl" for details on how to use that.  There are several
  152. advantages and disadvantages to using the perl version, so if you have
  153. perl, I would advise trying both packages to see which one better suits
  154. your environment.
  155.  
  156.    If you need help to interpret the results of COPS, look in the file
  157. "warnings", in the "doc" directory.  All of the individual programs in
  158. the COPS package have a man page there as well.
  159.  
  160.    For continuing use, multiple architecture sites, or other advanced
  161. COPS topics, check out "README.3".
  162.  
  163.   There are additional "readme" files for the following topics: Apollo
  164. and Xenix machines, C2 and other shadow passord files, NIS/Yellow Pages,
  165. and the COPS filter.  Look at the corresponding readme (note lower case)
  166. file for these in the "docs" directory -- e.g.  "docs/readme.apollo."
  167.  
  168. 4) Disclaimer and End Notes
  169. ----------------------------
  170.  
  171.    COPS is meant to be a tool to aid in the tightening of security, not
  172. as a weapon to be used by an enemy to find security flaws in a system.
  173. It may be argued that allowing anyone to have access to such a tool may
  174. be dangerous, but hopefully the overall benefit for systems that use
  175. this package will outweigh any negative impact.  To me it is akin to a
  176. law enforcement problem -- although telling the public how to break into
  177. a house may foster a slight rise in break-in attempts, the overall rise
  178. in public awareness of what to defend themselves against would actually
  179. result in a drop in break-ins.  The crackers with black hats already
  180. know how to crush system defenses and have similar tools, I'm sure.
  181. It's time we fought back.
  182.  
  183.    COPS is not the final answer to anyone's security woes.  You can use
  184. the system as long as you realize that COPS has no warranty, implied or
  185. otherwise, and that any problems that you may have with it are not my or
  186. any of the other authors' fault.  I will certainly attempt to help you
  187. solve them, if I am able.  If you have ideas for additional programs or
  188. a better implementation of any of the programs here, I would be very
  189. interested in seeing them.  COPS was the work of a LOT of people, both
  190. in writing code and in the testing phase (thanks, beta testers!).  For a 
  191. complete list of contributors, look at the file "XTRA_CREDIT".
  192.  
  193.    So, good luck, and I hope you find COPS useful as we plunge into UNIX
  194. of the 1990's.
  195.  
  196.    dan farmer
  197.    January 31, 1989
  198.    (Now January 31, 1990)
  199.    (Now November 17, 1991... how time goes on...)
  200.  
  201. # include "./disclaimer"
  202.  
  203. p.s.  Just for snix, here are some of the machine/OS's I know this
  204. sucker works on; far and away the most common problem was getting that
  205. stupid password cracking program to compile, followed by systems without
  206. the -ms package to nroff.  Some minor problems with config files -- I
  207. *think* these are all ok:
  208.  
  209. DECstation 2100, 3100, 5000, Ultrix 2.x, 3.x, 4.x (Ultrix is braindead.)
  210.  
  211. Sun 3's, 4's  (incl. Solbourne and clones) -- 3.x, 4.x
  212. Gould 9080 Powernode, hacked up Gould OS (whatever it is)
  213. sequent S-87 symmetry, dynix V3.x (both att & bsd universes; att required
  214.                        "BRAINDEADFLAGS = -lcrypt" to be uncommented.
  215. ETA-10P, Sys V R3 based
  216. Convex boxes, all types, OS's (up to 9.x, the most recent)
  217. Apollo dn3000 & dsp90, Domain SR 9.7, 10.x (see "readme.apollo")
  218. Vax 11/780, 4.x BSD (Mt. Xinu, tahoe and stock)
  219. Vaxstation, MicroVax, Vax 6320 & 8800, Ultrix 2.x, 3.x, 4.x
  220. HP900/370, HP-UX 6.x, 7.x
  221. Cray 2 & Y-MP, UNICOS 5.x, 6.x
  222. Amdahl 5880, UTS 580-1.2.3
  223. SGI 2500's, IRIX GL 3.6
  224. SGI 4D's, IRIX System V Release 3.x
  225. '286 & '386 Boxes, running Xenix (see "readme.xenix")
  226. AT&T 3B2 & 3B1, SysVR[3-4]
  227. CADMUS box (R3000 & 68020 cpu), SysVR3.2
  228. Pyramid, running 4.4c and 5.1a
  229.  
  230. Apple Mac IIci, running AUX 2.x.  The "test -z" seemed broken on this,
  231. but I only had a brief chance to test it out, but kuang didn't like it
  232. as a result.  I'll get a working version soon; everything seemed ok
  233. (change the /etc/servers line in "misc.chk").
  234.  
  235. NeXT, 1.x 
  236. (password stuff is different on this machine, though; cracking is
  237. strange.  Diffs anyone?  Also, /bin/test vs. shell builtin "test" is
  238. *weird*.)
  239.  
  240. Multimax 320, 12 Processors, 64Mb Memory, Encore Mach Version B1.0c (Beta)
  241. (no crypt(3) on this machine.  Sigh.)
  242.  
  243. IBM rs6000, AIX 3.1 (DEADBEEF about sums it up.)
  244.  
  245.   I've lost track of the others.  If you have some bizzare piece of
  246. hardware that you've run it on, I'd like to hear about it...
  247.