⟦a4bd1c046⟧

TextFile

.ps 12
.vs 12
.PH ````
.pn
.nr W 78
.ce 2
\fBCOPS and Robbers
UN*X System Security\fP
.sp
.sp
.PP
In the last few years, computer security has received a great deal
more attention than it has in the past.  Computerized 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 problems that face any
multiuser computing system, then discuss how these problems apply to UNIX\**
.FS
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 \*Qflavor\*U 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.
.FE
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 considered 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.
.PP
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
.ul
awk, grep, sed
as well as a working knowledge of shell and C programming are necessary
to understand the internal workings of the security system described in
this paper.
.PP
Although there is no reasonable way that all security problems can be
solved (at least not with a software solution) on any arbitrary UNIX
system, administrators and system 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 possible 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 potential 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].)
.PP
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:
.PP
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 mistake by a user
might cause little or no problem, but when someone with no
restrictions (or almost none) on their computer activity makes a mistake,
a security hole can result.  \*QI can trust my users\*U 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, systems, or procedures
can facilitate extra problems; a computing staff is often ill or
completely non-trained on new techniques and software.
Too often \*QRTFM\*U 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.  Especially misunderstood,
even by experienced UNIX system programmers, 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 problem), what checks are made to verify
that the person is really the owner of that account?  Are users that are
security 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 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.
.PP
A UNIX environment has no special defenses against this kind of
\*Qattack\*U.  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 periodically make a mistake; COPS has been
designed to aid in her/his never ending battle against the forces of
darkness.
.PP
2)  Physical security.  This is perhaps the most frustrating of all 
possible problems because it effects all computer systems and is often the
hardest to safeguard against.  Even if the software is secure, even if 
the system administrators 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
(especially 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.
.PP
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 tendency 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.
.PP
Other problems with authentication?  What computer hosts are
\*Qtrusted\*U 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 administrators to keep track of any unusual
activity?  What about \*QTrojan horses\*U -- 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?
.PP
Fortunately UNIX systems again have some fairly good tools to aid in
this fight.  Although finding simple passwords is indeed a trivial
task, forcing the users on a system 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
.ul
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
effective someone (usually the site administrator) must take the time to
examine the evidence.
.PP
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
happen.  \*QBack doors\*U that allow unauthorized entrances are sometimes
purposefully coded in -- for debugging, maintenance, 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 reluctance of a (usually) commercial developer
to admit any problems 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 product, not yours!
.PP
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 dysfunction.  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 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 fundamentals of computer security, think of
all the time and resources wasted tracking down the mistakes that keep
recurring time and time again.
.PP
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 \*Qtune\*U 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 anything from CPU time, response time, file space, or any
other commodity that a computer has to offer.
.PP
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 \*Qjust wanted to see what would happen\*U or had no idea
of the ramifications of their acts.  Someone who is truly experienced is 
very difficult to stop, and is certainly outside the realm of any
software security tool as discussed in this paper.  Fortunately, most
evil-doers are fairly inexperienced and ignorant, and when they make a
mistake, a watchful administrator 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.
.PP
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 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 impossibility 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:
.sp
Aho, Kernighan, and Weinberger 88
.sp
Baldwin 87
.sp
Fiedler and Hunter 86
.sp
Grampp and Morris 84
.sp
Wood and Kochran 86
.sp
.PP
Of course with all of the problems listed below, looking 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.  COPS
checks:
.PP
1)  \*Qvital\*U system files and directories to see if they
have dangerous permissions (usually either world-writable, or world-readable.)
Files and directories thought to be critical are in a configuration
file
.ul
is_able.lst.
Wildcards are useable like in UNIX; indeed, COPS
passes everything to the shell for expansion.
.sp
The program that performs this task is
.ul
is_able.chk
.PP
2)  Check devices for file systems to see if they are world-readable/writable,
plus check for any exported NFS file systems with no restrictions.
The file systems are normally found in /etc/fstab.
.sp
The program that performs this task is
.ul
dev.chk
.PP
3)  Check all files in system for SUID status, notifying the COPS user
of any changes in SUID status, and if any SUID files are world-writable,
shell scripts, or non-executable (program) files.
.sp
The program that performs this task is
.ul
suid.chk
and was written by Prentiss Riddle.
.PP
4)  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.
.sp
The program that performs this task is
.ul
passwd.chk
.PP
5)  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.
.sp
The program that performs this task is
.ul
group.chk
.PP
6)  Check passwords of users on system.
.sp
Method -- using the stock \*Qcrypt\*U command, compare the encrypted
password found in the /etc/passwd file against the following
(encrypted) guesses:
.sp
The login id (uid), information in the gecos field, and all single
letter passwords.
.sp
The program that performs this task is
.ul
pass.chk
and was written by Craig Leres and was modified by Seth Alford,
Roger Southwick, Steve Dum, and Rick Lindsley.  Bugs have been reported
and fixed by numerous people.
.PP
7)  Check the root path, umask, also if root is in /etc/ftpuser and
owns /bin, /etc, /etc/passwd, /.login, /.profile and /.rhosts, and
finally if a \*Q+\*U is in /etc/hosts.equiv.
.sp
The program that performs this task is
.ul
root.chk
.PP
8)  Examine the commands in /etc/rc* to ensure that none of the
files or paths used are world-writable.
.sp
The program that performs this task is
.ul
rc.chk
.PP
9)  Examine the commands in /usr/lib/crontab to ensure that none of the
files or paths used are world-writable.
.sp
The program that performs this task is
.ul
cron.chk
.PP
10)  Check all of the user home directories to ensure they are not
world writable.
.sp
The program that performs this task is
.ul
home.chk
and was written by John Owens.
.PP
11) Check important user files in user's home directories to ensure
they are not world writable, plus checks netrc files to see if they
are readable.  The files checked (all in the individual
users' home directory, all with the prefix \*Q.\*U):
.sp
rhosts profile login cshrc kshrc tcshr crhost
.sp
netrc forward dbxinit distfile exrc emacsrc logout
.sp
The program that performs this task is
.ul
user.chk
.PP
12) Checks ftp setup; anononymous ftp setup, if you support it.  This
seems to be fairly site specific; it tries to check for correct ownership,
file/directory permissions, etc.; for a complete description, check the
man page for ftp.chk.
.sp
The program that performs this task is
.ul
ftp.chk [-a]
.PP
13) Check for unexpected file system corruption or security breaches,
using CRC values that are generated from your system files, then
compared against previously calculated values.  As the author says:
\*QIt's nice to be able to say that you know all your files
are as they should be.\*U
.sp
The program that performs this task is
.ul
crc.chk.
Mark Mendel wrote most of
.ul
crc.c
and Jon Zeef wrote
.ul
crc_check.c
.PP
14) Checks a few miscellaneous potential security problems that really
don't belong anywhere else.  This includes looking to see if tftp &
rexecd are enabled, to check if the uudecode alias is in the mail
alias file and not commented out, if uudecode is either SUID or can
create SUID files, and if the programs inside the /etc/inetd.conf
or /etc/servers aren't world-writable.
.sp
The program that performs this task is
.ul
misc.chk
.PP
15) 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
.ul
U-Kuang
(rhymes with \*Qtwang\*U)
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 distribution.  For more information on this fascinating
security checker, see kuang.man.ms and [Baldwin 87].  I have rewritten
it in Bourne shell (it was in C-Shell) for further portability; Steve
Romig rewrote it in Perl for speed.
.PP
.PP
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 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.
.PP
Design Notes:
.PP
The programs that are described here were designed to address the
problems discussed above, but still be usable on as many UNIX
\*Qflavors\*U 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 improvements (that might not be too hard :-)),
suggestions, or other security programs that
you would like to see get further distribution can be sent to:
.PP
df@medusa.cs.purdue.edu
.PP
(That's me)
.PP
or
.PP
spaf@uther.cs.purdue.edu
.PP
(Dr. Eugene Spafford)
.PP
.PP
Enhancements I envision include:
.sp
i) Improved speed and portability without sacrificing functionality
(pretty obvious, I guess....)
.sp
ii) A level of severity assigned to each warning; anything that could 
compromise root instantly (root having no password, for example) might
have a level 0 priority, while simply having a user with a writable home
directory might only be level 3.  This way the system could be run at
a certain threshold level, or simply have the set of warnings
prioritized for a less sophisticated administrator.
.sp
iii) The eradication of any design flaws or coding errors that are in
the COPS system.
.PP
The main purpose of creating the COPS system was twofold; the first was
to foster an understanding of the security 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.
.PP
Some of the advantages to using a system such as COPS are:
.sp
i) Nearly Continuous monitoring of traditional problem areas.
.sp
ii) A new system can be checked before being put into production.
.sp
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 security dilemmas.
.PP
And a couple of disadvantages:
.sp
i) An administrator could get a false sense of security from running
these programs.  Caveat emptor (ok, they are free, but still beware.)
.sp
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.
.sp
iii) Badguys can get these tools.  You know -- the guys with black hats.
What happens when they get a copy of this package?  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.
.PP
.ul
Results of Running COPS:
.PP
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 running DYNIX 3.0.12, on a pair of Suns (a
3/280 and 3/50) running 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 administration, 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.
.PP
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.
.PP
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 weren't going to give it to me.
The one book devoted to UNIX security ([Kochran and Wood 86]) was good,
but the programs 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 security discussion group on the network ([Various Authors
84-]), from which I received some excellent ideas for this project, but
it is very restrictive to whom it allows to participate.  I hope that
with the release of this security system it will not only help stamp
out problems with UNIX security, but would encourage people to exchange
ideas, programs, problems and solutions to the computer community at large.

Dan Farmer
September 29, 1989
(latest changes on January 7, 1991)
.PP
.ul
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 programs created by Robert Morris, Matt Bishop, and
other capable 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 inspirational computer work.
And of course without Peg, none of this would have come into being.
Thanks again to all of you.
.bp
.ce
.ul
BIBLIOGRAPHY

.sp
_, UNIX Programmers Manual, 4.2 Berkeley Software Distribution,
Computer Science Division, Department of Electrical
Engineering and Computer Science University of California,
Berkeley, CA, August 1983.
.sp
_, DYNIX(R) V3.0.12 System Manuals, Sequent Computer Systems, Inc., 1984.
.sp
Aho, Alfred V., Brian W. Kernighan, and Peter J. Weinberger, The
AWK Programming Language, Addison-Wesley Publishing Company, 1988.
.sp
Authors, Various, UNIX Security Mailing List/Security Digest,
December 1984 -.
.sp
Baldwin, Robert W., Crypt Breakers Workbench, Usenet, October
1986.
.sp
Baldwin, Robert W., Rule Based Analysis of Computer Security,
Massachusetts Institute of Technology, June 1987.
.sp
Bauer, David S. and Michael E. Koblentz, NIDX - A Real-Time
Intrusion Detection Expert System, Proceedings of the Summer
1988 USENIX Conference, Summer, 1988.
.sp
Bishop, Matt, Security Problems with the UNIX Operating System,
Department of Computer Sciences, Purdue University, January
31, 1983.
.sp
Bishop, Matt, How to Write a Setuid Program, April 18, 1985.
.sp
Denning, Dorothy, Cryptography and Data Security, Addison-Wesley
Publishing Company, Inc, 1983.
.sp
Duff, Tom, Viral Attacks On UNIX System Security, Proceedings of
the Winter 1988 USENIX Conference, Winter, 1988.
.sp
Fiedler, David and Bruce Hunter, UNIX System Administration,
Hayden Book Company, 1986.
.sp
Grampp, F. T. and R. H. Morris, "UNIX Operating System Security,"
AT&T Bell Laboratories Technical Journal, October 1984.
.sp
Kaplilow, Sharon A. and Mikhail Cherepov, "Quest -- A Security
Auditing Tool," AT&T Bell Laboratories Technical Journal,
AT&T Bell Laboratories Technical Journal, May/June 1988.
.sp
Morris, Robert and Ken Thompson, "Password Security : A Case
History," Communications of the ACM, November 1979.
.sp
Reed, Brian, "Reflections on Some Recent Widespread Computer
Break-ins," Communications of the ACM, vol. Vol 30, No. 2,
February 1987.
.sp
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.
.sp
Smith, Kirk, Tales of the Damned, UNIX Review, February 1988.
.sp
Spafford, Eugene H., The Internet Worm Program: An Analysis,
Purdue Technical Report CSD-TR-823, Nov 28, 1988.
.sp
Spafford, Eugene H., 1989.  Private Communications
.sp
Bruce Spence, spy: A UNIX File System Security Monitor, Workshop
Proceedings of the Large Installation Systems Administration III,
September, 1988.
.sp
Stoll, Clifford, Stalking the Wily Hacker, Volume 31, Number 5,
Communications of the ACM, May 1988.
.sp
Thompson, Ken, Reflections on Trusting Trust, Volume 27, Number
8, Communications of the ACM, August 1984.
.sp
Wood, Patrick and Stephen Kochran, UNIX System Security, Hayden
Books, 1986.
.sp
Wood, Patrick, A Loss of Innocence, UNIX Review, February 1988.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦a4bd1c046⟧ TextFile

Derivation

TextFile
