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.2.pl < prev    next >
Text File  |  1992-03-10  |  12KB  |  249 lines

  1.  
  2.   This file covers the configuration and execution of the perl version
  3. of COPS (or p-COPS).  It requires a version of perl > 3.18 to work.  For
  4. a rough time estimate, it took about 1.25 minutes on my host (a
  5. SPARCstation 2) to generate a report (not including the SUID checker,
  6. which does a find on "/").  p-COPS is roughly functionally equivalent to
  7. the shell/C version (sans the CRC checker), but has some important
  8. differences:
  9.  
  10. Advantages:
  11.  
  12. o  Perl is a real language (not that C isn't -- I'm comparing it mostly 
  13.    to shell programming.)  It has almost no arbitrary limitations,
  14.    unlike shell (amount of data a variable can hold, etc.)  All the
  15.    information that COPS finds (especially from the password file, which
  16.    is a major source of the security problems in a UN*X system) can be
  17.    easily passed between modules.  As a result, the programs are more
  18.    modular, easier to debug, and a lot more fun to write.
  19.  
  20. o  Perl is faster (even though the "hard" things are done mostly in C in
  21.    the shell/C version, a lot of time is wasted due to the fact that
  22.    almost no data sharing is done) and doesn't require any compilation
  23.    (aside from the perl interpreter itself.)  This last point is  
  24.    particularily nice for sites with multiple architectures.
  25.  
  26. o  p-COPS has a pair of very nice features -- the configuration file and 
  27.    the recursive searching for writable files.  The config file is a big
  28.    win: no more digging through code, trying to change some variable
  29.    value and it gives control over which modules are run and many other
  30.    important options. 
  31.  
  32. Disadvantages:
  33. o  Perl.  It's a relatively new language that is changing frequently.
  34.    The code, greatly boosted in complexity and efficiency by tom 
  35.    christiansen's hard work, can cause core dumps and other problems
  36.    on some platforms.  On others, it works fine.  Also, since perl is
  37.    changing, future versions of perl might break previously working
  38.    code.  It all rests in larry wall's capable hands.  Caveat Usor. 
  39.  
  40. o  p-COPS has not been tested thoroughly.  It seems to work, on some
  41.    machines, but is sure to contain more bugs than the simpler shell/C
  42.    version. 
  43.  
  44.   Ok -- now you're warned.  I highly suggest giving it a try -- here's
  45. how to use p-COPS:
  46.  
  47. 1) How to Configure p-COPS
  48. ---------------------------
  49.  
  50.   Although most of the programs in p-COPS are written entirely in perl,
  51. some shell programs are used for simplicity (diff, ypcat, etc.)  This
  52. shouldn't be a problem, but System V users, other Non-BSD systems, or
  53. sites with commands in strange places should run a program called
  54. "reconfig.pl" to change the pathnames of the executable programs called
  55. when using COPS.  If your system does not use the paths listed in the
  56. perl programs, try running it; COPS should run fine then, if it can find
  57. all of the commands (reconfig should tell you if it cannot). If trouble
  58. persists, you will have to edit the configuration file "cops.cf" to
  59. change the paths to your executable files by hand.  A drag, I know.  If
  60. in doubt, run reconfig.pl.  It can't hurt.  Or at least shouldn't.  If
  61. it does hurt, you're probably in touble anyway.
  62.  
  63. 2) Running p-COPS for the 1st Time
  64. ---------------------------------
  65.  
  66.    Since most of p-COPS was written and tested mostly on just a few
  67. machines (at least compared to the total number out there!), you may
  68. have significant differences that were not anticipated -- unfortunately
  69. (or fortunately) perl and UNIX are not quite standardized yet.
  70.  
  71.    p-COPS is run by going into the "perl" subdirectory and typing
  72. "cops".  "cops" is a perl program that looks inside the configuration
  73. file ("cops.cf"), runs each of the programs listed there, accumulates
  74. the output, and then either mails any results or stores them in a file.
  75. "suid.chk" is the only package that is usually meant to be run
  76. separately (although it can be run via the config file), simply because
  77. it can take a long time to run, and because it needs a privileged
  78. account to run it; look at "suid.man" for more information.  By all
  79. means, however, do not ignore the SUID checker!  Run it at least once a
  80. week, if possible more (daily?); intruders into a system often leave
  81. SUID files to gain privileges later.  The program "crc.chk" (part of the
  82. shell/C version of COPS) should also be run; read the file "CRC.README",
  83. and the man page for more information.
  84.  
  85.    -- Read the technical report to understand what COPS is doing and
  86.       what is going on -- "cops.report".  This gives a look at the 
  87.       philosophies, design, and general outlay of the COPS system and
  88.       UNIX security.  This can be forsaken by those who just want to get
  89.       to the results/see some action (people like me), but it might
  90.       prove interesting to some.
  91.  
  92.    -- On line 12 in the configuration file, "cops.cf":
  93.  
  94.         $SECURE_USERS="foo@bar.edu";
  95.  
  96.       $SECURE_USERS should be your own login id, or that of whomever
  97.       you designate as the recipient of the output.
  98.  
  99.    -- Set "$MMAIL=0" in the "cops.cf" file (line 10; this is the default).
  100.       This will prevent a large mail file from choking the mailer.  All of
  101.       the output will be put into a file called "year_month_day" (obviously,
  102.       that's like: "1992_Dec_31", not actually the words,
  103.       "year_month_day" :-)), which is automatically placed by COPS
  104.       in a directory that has the same name as the host it was run on
  105.       (e.g., your own hostname).  Hence, the final report will be in
  106.       "./hostname/year_month_day".  Setting this variable to 1 will
  107.       cause the report to be mailed to $SECURE_USERS.
  108.  
  109.    -- Look at the directory and file configuration file, "is_able.lst" 
  110.       This contains critical files that COPS checks for group and world 
  111.       writability and readability.  Add or delete whatever files/
  112.       directories you wish; if a file doesn't exist, COPS will
  113.       effectively ignore it.  (If you don't know or are uncertain what
  114.       files/directories are important, what is given there is a good set
  115.       to start with on most systems.)
  116.  
  117.    -- If you allow anonymous ftp access to your system, add a "-a" flag 
  118.       to "ftp.chk" on line 83 of "cops.cf".  Right now, it is set up so 
  119.       that key files and directories are expected to be owned by root; 
  120.       however, it has provisions for two owners, $primary and $secondary
  121.       -- you may wish to change the second to "ftp", or some other user. 
  122.       Read the man page for ftp.chk, or look at "ftp.chk" for further
  123.       notes. 
  124.  
  125.    -- You may wish to comment out the password checker (line 72 in the 
  126.       "cops.cf" file), if you wish for immediate gratification.
  127.       However, it is an abysmal idea to do this in general (unless you
  128.       use another password cracker, like "crack" (see the "extensions"
  129.       directory for more info.)  If you are using yellow pages/NIS, read
  130.       "readme.yp" for tips on how to check passwords with it; if you are
  131.       using shadow passwords, read "readme.shadow".
  132.  
  133.    -- Run the crc checker, "crc.chk" if you desire; unfortunately, this
  134.       hasn't been ported to perl yet, so you'll have to either use the
  135.       shell version or wait for the port (or write it and send it to me...)
  136.  
  137.   You should be ready to roll.  COPS is run by simply typing "cops" (you
  138. may wish to put it in the background).  If you followed my advice and
  139. set "$MMAIL=0" in the "cops.cf" configuration file, after COPS is
  140. finished there will be a report file created ("year_month_day") that
  141. lists the time and machine it was created on.  Otherwise, COPS mails the
  142. report to the user(s) listed on the line '$SECURE_USERS="foo@bar.edu"'.
  143. There is a file "warnings" (in the "../docs" directory), which contains
  144. the warning messages COPS uses, as well as a brief explanation of how
  145. the message might pertain to your system and finally a suggestion as
  146. how to "fix" any problem.
  147.  
  148.    WARNING NOTE: Change the configuration file "cops.cf" to reflect who
  149. you want the output sent to and where the location of the program is
  150. BEFORE running the program.
  151.  
  152.  
  153. 2) Further notes and use of p-COPS, plus things for "perl literates"
  154. ---------------------------------------------------------------------
  155.  
  156.    The only important thing you have to set in the "cops" main file (or
  157. via the "-s" flag) is the secure directory, which by default is ".".
  158. This is where COPS will look for the config file and all the programs.
  159. Also, if something is flagged as world-writable, and the file itself is
  160. not writable but the parent directory is, then there will be an asterix
  161. after the warning (e.g. /usr/foo/bar is World Writable! (*).)
  162.  
  163. As said in the config file -- "cops.cf" (a "#" sign denotes comments):
  164.  
  165. # anything beginning with /^\s*[$@%&]/ will be eval'd
  166.  
  167.   In general, you can put variables and programs that will be run inside
  168. the config file.  Variables look startlingly like they do in normal perl
  169. (look at the "PROGRAMS" section below for more on running programs);
  170. e.g.:
  171.  
  172. $MMAIL         = 0;         # send mail instead of generating reports
  173. $ONLY_DIFF     = 0;          # only send diff from last time
  174. $SECURE_USERS   = "root";     # user to receive mailed report
  175.  
  176.    Setting something to "0" (without quotes is fine) generally means
  177. that the option is not used.  "1" (or non-zero values, if you feel
  178. gutsy) is used for a positive/true/whatever value.  The variables in
  179. general should be very similar to their normal COPS counterparts; in
  180. this case, setting $MMAIL to 1 would mean to mail info to the user listed
  181. in SECURE_USERS.  If $ONLY_DIFF is 1, it will only mail reports if change
  182. has occurred.
  183.  
  184.   In general, variables in the main package are for COPS itself, whereas
  185. those with package qualifiers are for a particular routine or for
  186. auxiliary routines.  For instance, the following lines:
  187.  
  188. # this one says to ignore warnings about paths matching these regexps
  189. @chk_strings'ignores = ( '^/tmp/?', '^/(var|usr)/tmp/?' );
  190.  
  191.   "chk_strings" is a routine that checks for writable programs within
  192. other programs, usually executed by root, such as /etc/rc and crontab.
  193. This line says to ignore any files that start with a "/tmp", "/var/tmp",
  194. or "/usr/tmp".  If you have a file or set of files that always are
  195. returning writable that are inside your rc and cron files, then you can
  196. put exceptions here.  One possibility is that you don't care about files
  197. created by other programs, so that anything after a ">" should be
  198. ignored.  You might add something like '>.*' to ignore files like
  199. "/usr/bar/snowcone", in a line like "/foo/bar/command >
  200. /usr/bar/snowcone".
  201.  
  202.    Next, there is a nifty option that does recursive searching inside
  203. the files chk_strings looks at.  This is neat... get it working by
  204. setting this to 1:
  205.  
  206. $chk_strings'recurse = 1;
  207.  
  208.   So, if you have a line like this in /etc/rc:
  209.  
  210. /usr/bin/foo > /dev/console
  211.  
  212.   It will examine "/usr/bin/foo" for programs inside of it -- and it
  213. will keep going until it has exhausted all possibilities.  So you can
  214. get warning messages like:
  215.  
  216. Warning!  File /foo/bar (inside /usr/local/X11R4/bin/X inside
  217. /usr/local/X11R4/bin/xdm inside /etc/rc.local) is _World_ writable!
  218.  
  219.   Fun stuff.  No one can hide, now...
  220.  
  221. PROGRAMS
  222. =========
  223.  
  224.   Running a program within p-COPS is easy; you just have the program
  225. with any options by itself on a line.  Semi-colons are not welcome here.
  226. E.g.:
  227.  
  228. # first test the security of the root account
  229. root.chk
  230.  
  231.   Some variables specific to the various programs are here as well, e.g.:
  232.  
  233. # now of the various devices.  -g means to check group writability, too
  234. $MTAB    = '/etc/fstab';
  235. $EXPORTS = '/etc/exports';
  236. $TAB_STYLE = 'new';
  237. dev.chk -g 
  238.  
  239.   This is specifying the export files, etc., and saying that you should
  240. use the "new" format style in the exports file.  Ultrix, etc. uses the
  241. old style.  Suid.chk eats up time -- consider the "-n" flag for systems
  242. that have big NFS mounted disks.  And that's it -- the rest should be
  243. similar to the shell version of cops, and theoretically should give you
  244. similar or the same results.
  245.  
  246.   Good luck!  Send bugs, flames, etc. to zen@death.corp.sun.com
  247.  
  248.  -- dan
  249.