COPS and Robbers
UN*X System Security
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
February 19, 1991
- 6 -
UNIX security holes. The COPS system uses a variety of
these problems to see if there are any cracks in a given
UNIX security wall. These methods correspond to some of the
problems discussed above; specifically to administrators,
system programmers, and computer operators; authentication;
ignorance; unauthorized permissions or privileges; and
finally crackers/hackers/evil twin brothers (numbers 1,3,5,
and 6.) It is very difficult, almost a practical impossi-
bility to give software assistance to problems in physical
security, and finally bugs or features that are present in a
given UNIX system are possible to detect, but are not
covered in this system (yet). The design of most of the the
programs were at least described if not outlined from the
following sources:
Aho, Kernighan, and Weinberger 88
Baldwin 87
Fiedler and Hunter 86
Grampp and Morris 84
Wood and Kochran 86
Of course with all of the problems listed below, look-
ing at the actual source code of the program is very
instructive -- each numbered section lists the corresponding
program that is used to perform the check:
1) COPS Checks "vital" system directories to see if
they are world-writable. Directories listed as critical are
in a configuration file and are initially:
/ /etc /usr
/bin /Mail /usr/spool
/usr/adm /usr/etc /usr/lib
/usr/bin /usr/etc /usr/spool/mail
/usr/spool/uucp /usr/spool/at
The method COPS uses to detect problems -- read through
a configuration file (dir.chklst) containing all of the
potential danger spots, and then simply comparing each
directory modes with a bit mask to see if it is world writ-
able. The program that performs this task is dir.chk
2) Check "vital" system files to see if they are
world-writable. Files listed as critical are in a confi-
guration file (file.chklst) and are initially:
February 19, 1991
- 7 -
/.*
/etc/*
/bin/*
/usr/etc/yp*
/usr/lib/crontab /usr/lib/aliases /usr/lib/sendmail
The wildcards are used like in UNIX, so these would include
(some of the more important files):
/.login /.profile /.cshrc /.crontab /.rhost
/etc/passwd /etc/group /etc/inittab /etc/rc
/etc/rc.local /etc/rc.boot /etc/hosts.equiv /etc/profile
/etc/syslog.conf /etc/export
As well as the executable command files (among others):
sh,csh, and ls.
Method -- again read through a configuration file list-
ing all of the files to be checked, comparing each in turn
with a write mask. The program that performs this task is
file.chk
3) Check "vital" system files to see if they are
world-readable, plus check for a NFS file system with no
restriction. These critical files are:/dev/kmem /dev/mem All file systems found in /etc/fstab
Plus a small number of user selectable files -- initially
set to include /.netrc, /usr/adm/sulog, and /etc/btmp.
Method -- checking each in turn against a read mask for
their read status. The file system names are read from
/etc/fstab, the selectable files are kept in a variable.
The program that performs this task is dev.chk
4) Check all files in system for SUID status, notify-
ing the COPS user of any changes in SUID status.
Method -- Use the "find" command on the root directory (this
must be done by root to avoid missing any files unreadable
but still dangerous.) The previous run will create a file
February 19, 1991
- 8 -
that can be checked against the current run to keep track of
changes in SUID status and any new SUID files. The program
that performs this task is suid.chk and was written by Pren-
tiss Riddle.
5) Check the /etc/passwd file (and the yellow pages
password database, if applicable) for null passwords,
improper # of fields, non-unique user-id's, non-numeric
group id's, blank lines, and non-alphanumeric user-id's.
Method -- Read through password file, flag any differences
with normal password file, as documented in "man 5 passwd".
Fortunately, the syntax of the password file is relatively
simple and rigid. The program that performs this task is
passwd.chk
6) Check the /etc/group file (and the yellow pages
database, if applicable) for groups with passwords, improper
# of fields, duplicate users in groups, blank lines, and
non-unique group-id's.
Method -- Read through group file, flag any differences with
normal group file as documented in "man 5 group". Again,
the syntax of this file is fairly simple. The program that
performs this task is group.chk
7) Check passwords of users on system.
Method -- using the stock "crypt" command, compare the
encrypted password found in the /etc/passwd file against the
following (encrypted) guesses:
The login id (uid), information in the gecos field, and all
single letter passwords.
The program that performs this task is pass.chk and was
written by Craig Leres and was modified by Seth Alford,
Roger Southwick, Steve Dum, and Rick Lindsley.
8) Check the root path, umask, and if root is in
/etc/ftpuser.
Method -- look inside the /.profile and /.cshrc files to
ensure that all of the directories listed are not world
writable, that "." isn't anywhere in the path, and that the
umask is not set to create world writable files. The pro-
gram that performs this task is root.chk
9) Examine the commands in /etc/rc* to ensure that
none of the files or paths used are world-writable.
Method -- grep through the files and examine any strings
that start with "/" for writability. The program that
February 19, 1991
- 9 -
performs this task is rc.chk
10) Examine the commands in /usr/lib/crontab to ensure
that none of the files or paths used are world-writable.
Method -- grep through the crontab file and examine any
strings after field five (first five are not files, but how
crontab is to be run) that start with "/" for writability.
The program that performs this task is cron.chk 11) Check
all of the user home directories to ensure they are not
world writable.
Method -- get all of the home directories using the system
call getpwent() and then for every home directory found,
check the write permissions of of the home directory against
a bit mask. The program that performs this task is home.chk
and it was written by John Owens.
12) Check important user files in user's home direc-
tories to ensure they are not world writable. The files
checked (all in the individual users' home directory, all
with the prefix "."):
rhost profile login cshrc kshrc tcshr crhost
netrc forward dbxinit distfile exrc emacsrc
Method -- using the same system call as #10, determine user
home directory. Then simply check all of the above files
against a bit mask. The program that performs this task is
user.chk
13) Given a goal to compromise, such as user root, and
a list of user and group id's that can be used in an attempt
to achieve the goal, this security tool will search through
the system until it verifies that the goal is compromisible
or not. The program that performs this tricky task is part
of the U-Kuang (rhymes with "twang") system. Robert Baldwin
was kind enough to allow me to include this security checker
(a fine security machine in it's own right) within this dis-
tribution. For more information on this fascinating secu-
rity checker, see kuang.man.ms and [Baldwin 87]. I have
rewritten it in Bourne shell (it was in C-Shell) for further
portability.
None of programs listed above certain cover all of the
possible areas that can harm a system, but if run together
they can aid an overworked administrator to locate some of
the potential trouble spots. The COPS system is not meant
to be a panacea against all UNIX security woes, but an
administrator who examines the security toolbox programs and
this research paper might reduce the danger of their UNIX
system being compromised -- and that's all any security tool
can ever hope to do. The COPS system could never replace a
February 19, 1991
- 10 -
vigilant administration staffed with knowledgeable people,
but hopefully, as administrators look into the package, more
comprehensive programs will come into being, covering more
of the problems that will continue as the latest versions of
UNIX continue to grow.
Design Notes:
The programs that are described here were designed to
address the problems discussed above, but still be usable on
as many UNIX "flavors" as possible. Speed was sacrificed
for simplicity/portability; hopefully the tools here will
either be replaced or modified, as by no means are they the
final word or solution to _any_ of these problems; indeed,
it is my hope that after other programmers/administrators
see this report, they will create newer, better, and more
general tools that can be re-distributed periodically. None
of the programs need to be run by root to be effective, with
the exception of the SUID checker (to ensure that all files
are checked.) Some of the tools were written by myself, the
others were written by other programmers on the network and
(with their permission) presented here. All of the programs
in this report are in the public domain, with the exception
of Robert Baldwin's U-Kuang system; they all exist solely to
be used and modified to fit your needs. If they are re-
distributed, please keep them in their original form unless
it is clearly stated that they were modified. Any improve-
ments (that might not be too hard :-), suggestions, or other
security programs that you would like to see get further
distribution can be sent to:
df@medusa.cs.purdue.edu
(That's me)
or
spaf@uther.cs.purdue.edu
(Dr. Eugene Spafford)
Note that the COPS system is still in an infancy stage
-- although it has been tested on a variety of computers at
Purdue, it has not undergone any serious trials.
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, 1990
- 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.Source URL: http://gbejadacosta.blogspot.com/2010/12/cops-and-robbers-unx-system-security.html
Visit Gbejada Costa for Daily Updated Hairstyles Collection
