When the first version of this book appeared in 1991, many people
thought that the words "Unix
security" were an oxymoron—two words that
appeared to contradict each other, much like the words
"jumbo shrimp" or
"Congressional action." After all,
the ease with which a Unix guru could break into a system, seize
control, and wreak havoc was legendary in the computer community.
Some people couldn't even imagine that a computer
running Unix could ever be made secure.
Since then, the whole world of computers has changed. These days,
many people regard Unix as a relatively secure operating system.
While Unix was not originally designed with military-level security
in mind, it was built both to withstand limited external attacks and
to protect users from the accidental or malicious actions of other
users on the system. Years of constant use and study have made the
operating system even more secure, because most of the Unix security
faults have been publicized and fixed. Today, Unix is used by
millions of people and many thousands of organizations around the
world, all without obvious major mishaps.
But the truth is, Unix really hasn't become
significantly more secure with its increased popularity.
That's because fundamental flaws still remain in the
operating system's design. The Unix
remains a single point of attack: any intruder or insider
who can become the Unix superuser can take over the system,
booby-trap its programs, and hold the computer's
users hostage—sometimes even without their knowledge.
One thing that has improved is our understanding of how to keep a
computer relatively secure. In recent years, a wide variety of tools
and techniques have been developed with the goal of helping system
administrators secure their Unix computers. Another thing that has
changed is the level of understanding of Unix by system
administrators: now it is relatively easy for companies and other
organizations to hire a professional system administrator who will
have the expertise to run their computers securely.
The difference between a properly secured Unix system and a poorly
secured Unix system is vast, and the difference between a system
administrator with the knowledge and motivation to secure a system
and one without that knowledge or motivation can be equally vast.
This book can help.
What This Book Is
This book is a practical guide to security for
Unix and Unix-like (e.g., Linux) systems. For users, we explain what
computer security is, describe some of the dangers that you may face,
and tell you how to keep your data safe and sound. For
administrators, we explain in greater detail how Unix security
mechanisms work and how to configure and administer your computer for
maximum protection. For those who are new to Unix, we also discuss
Unix's internals, its history, and how to keep
yourself from getting burned.
Is this book for you? If you administer a Unix system, you will find
many tips for running your computer more securely. If you are new to
the Unix system, this book will teach you the underlying concepts on
which Unix security is based. If you are a developer, this book will
give you valuable details that are rarely found together in one
place—it might even give you an idea for a new security
We've collected helpful information concerning how
to secure your Unix system against threats, both internal and
external. In most cases, we've presented material
and commands without explaining in any detail how they work, and in
several cases we've simply pointed out the nature of
the commands and files that need to be examined;
we've assumed that a typical system administrator is
familiar with the commands and files of his system, or at least has
the manuals available to study.
Some people may think
that it is a cop-out for a book on computer security to advise the
reader to read her system manuals. But it's not. The
fact is, computer vendors change their software much faster (and with
less notice) than publishers bring out new editions of books. If you
are concerned about running your computer
securely, then you should take the extra time to read your manuals to
verify what we say. You should also experiment with your running
system to make sure that the programs behave the way they are
Thus, we recommend that you go back and read through the manuals
every few months to stay familiar with your system. Sometimes
rereading the manuals after gaining new experience gives you added
insight. Other times it reminds you of useful features that you
haven't used yet. Many successful system
administrators have told us that they make it a point to reread all
their manuals every 6 to 12 months!
Certain key parts of this book were written with the novice user in
mind. We have done this for two reasons: to be sure that important
Unix security concepts are presented to the fullest and to make
important sections (such as those on file permissions and passwords)
readable on their own. That way, this book can be passed around with
a note saying, "Read Chapter 4 to
learn about how to set passwords."
What This Book Is Not
This book is not intended to be a Unix tutorial, nor is it a system
administration tutorial—there are better books for that (see
Appendix C), and good system administrators need to
know about much more than security. Use this book as an adjunct to
tutorials and administration guides.
This book is also not a general text on computer
security—we've tried to keep the formalisms to
a minimum. Thus, this is not a book that is likely to help you design
new security mechanisms for Unix, although we have included a chapter
on how to write more secure programs.
We've also tried to minimize the amount of
information in this book that would be useful to people trying to
break into computer systems. If that is your goal, then this book
probably isn't for you.
We have also tried to resist the temptation to suggest:
Replacements for your standard commands
Modifications to your kernel
Other significant programming exercises to protect your system
The reason has to do with our definition of
practical. For security measures to be
effective, they need to be generally applicable. Most users of
Solaris and other
commercial versions of Unix do not have access to the source code:
they depend upon their vendors to fix bugs. Even most users of
so-called "open source" systems
such as Linux and
FreeBSD rely on others to
fix bugs—there are simply too many flaws and not enough time.
Even if we were to suggest changes, they might not be applicable to
every platform of interest. Experience has shown that making changes
often introduces new flaws unless the changes are extremely simple
There is also a problem associated with managing wide-scale changes.
Not only can changes make the system more difficult to maintain, but
changes can be impossible to manage across many architectures,
locations, and configurations. They also will make vendor maintenance
more difficult—how can vendors respond to bug reports for
software that they didn't provide?
Last of all, we have seen programs and suggested fixes posted on the
Internet that are incorrect or even dangerous. Many administrators of
commercial and academic systems do not have the necessary expertise
to evaluate the overall security impact of changes to their
system's kernel, architecture, or commands. If you
routinely download and install third-party patches and programs to
improve your system's security, your overall
security may well be worse in the long term.
For all of these reasons, our emphasis is on using tools provided
with your operating systems. Where there are exceptions to this rule,
we will explain our reasoning.
Third-Party Security Tools
are many programs, systems, and other kinds of software tools that
you can use to improve the security of your computer system. Many of
these tools come not from your own organization or from the vendor,
but instead from a third party. In recent years, third-party tools
have been provided by corporations, universities, individuals, and
even the computer underground.
When we published the first version of this book, there were precious
few third-party security tools. Because the tools that did exist were
important and provided functionality that was not otherwise
available, we took an inclusive view and described every one that we
thought significant. We tried that same approach when the second
edition of this book was published and we suffered the consequences.
There were simply too many tools, and our printed descriptions soon
were out of date.
With this third edition of Practical Unix and Internet
Security, we have taken a fundamentally different
approach. Today, tools are both being developed and being abandoned
at such a furious rate that it is no longer practical to mention them
all in a printed volume. Furthermore, many of the better tools have
been incorporated into the operating system. Therefore, in this
edition of the book we will, for the most part, discuss only tools
that have been integrated into operating system distributions and
releases. We will not devote time (and precious pages) to explaining
how to download and install third-party tools or