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 superuser 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.
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 product.
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.
A Note About Your Manuals
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 documented.
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."
 Remember to pass around the book itself or get another copy to share. If you were to make a photocopy of the pages to circulate, it could be a significant violation of the copyright. This sets a bad example about respect for laws and rules, and conveys a message contrary to good security policy.
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 and well-understood.
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.
There 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 modifications.
 Articles about current security tools, with detailed configuration information, appear regularly on the O'Reilly web site and the O'Reilly Network, as well as on a variety of security-related sites. In addition, see Appendix D for some suggestions.