cops and robbers-unix system security.txt

1000 HOWTOs for various needs [WINDOWS]

                      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