In today's world of international networks and electronic commerce, every computer system is a potential target. Rarely does a month go by without news of some major network or organization having its computers penetrated by unknown computer criminals. Although some computer "hackers" (see the sidebar below) have said that such intrusions are merely teenage pranks or fun and games, these intrusions have become more sinister in recent years: computers have been rendered inoperable; records have been surreptitiously altered; software has been replaced with secret "back doors" in place; proprietary information has been copied without authorization; and millions of passwords have been captured from unsuspecting users.
Even if nothing is removed or altered, system administrators must often spend hours or days reloading and reconfiguring a compromised system to regain some level of confidence in the system's integrity. There is no way to know the motives of an intruder and the worst must be assumed. People who break into systems simply to "look around" do real damage, even if they do not read confidential mail and do not delete any files. If computer security was once the subject of fun and games, those days have long since passed.
Many different kinds of people break into computer systems. Some people - perhaps the most widely publicized - are the equivalent of reckless teenagers out on electronic joy rides. Like youths who "borrow" fast cars, their main goal isn't necessarily to do damage, but to have what they consider to be a good time. Others are far more dangerous: some people who compromise system security are sociopaths, joyriding around the networks bent on inflicting damage on unsuspecting computer systems. Others see themselves at "war" with rival hackers; woe to innocent users and systems who happen to get in the way of cyberspace "drive-by shootings!" Still others are out for valuable corporate information, which they hope to resell for profit. There are also elements of organized crime, spies and saboteurs motivated by both greed and politics, terrorists, and single-minded anarchists using computers and networks.
The most dangerous computer criminals are usually insiders (or former insiders), because they know many of the codes and security measures that are already in place. Consider the case of a former employee who is out for revenge. The employee probably knows which computers to attack, which files will cripple the company the most if deleted, what the defenses are, and where the backup tapes are stored.
Despite the risks, interest in computer networking and the Internet has never been greater. The number of computers attached to the Internet has approximately doubled every year for nearly a decade. By all indications, this growth is likely to continue for several years to come. With this increased interest in the Internet, there has been growing interest in UNIX as the operating system of choice for Internet gateways, high-end research machines, and advanced instructional platforms.
Years ago, UNIX was generally regarded as an operating system that was difficult to secure. This reputation was partially unfounded. Although part of UNIX 's poor reputation came from design flaws and bugs, a bigger cause for blame rested with the traditional use of UNIX and with the poor security consciousness of its users. For its first 15 years, UNIX was used primarily in academia, the computing research community, the telephone company, and the computer industry itself. In most of these environments, computer security was not a priority (until perhaps recently). Users in these environments often configured their systems with lax controls, and even developed philosophies that viewed strong security as something to avoid. Because they cater to this community (and hire from it), many UNIX vendors have developed a culture that has been slow to incorporate more practical security mechanisms into their products.
Perhaps the best known demonstration of UNIX vulnerability to date occurred in November 1988. That was when Robert T. Morris released his infamous "Internet worm" program, which spread to thousands of computers in a matter of hours. That event served as a major wake-up call for many UNIX users and vendors. Since then, users, academics, and computer manufacturers have usually worked together to try to improve the security of the UNIX operating system. Many of the results of those efforts are described in this book.
But despite the increasing awareness and the improvements in defenses, the typical UNIX system is still exposed to many dangers. The purpose of this book is to give readers a fundamental understanding of the principles of computer security and to show how they apply to the UNIX operating system. We hope to show you practical techniques and tools for making your system as secure as possible, especially if it is running some version of UNIX . Whether you are a user or administrator, we hope that you will find value in these pages.
Terms like security , protection , and privacy often have more than one meaning. Even professionals who work in information security do not agree on exactly what these terms mean. The focus of this book is not formal definitions and theoretical models so much as practical, useful information. Therefore, we'll use an operational definition of security and go from there.
If you expect the data entered into your machine today to be there in a few weeks, and to remain unread by anyone who is not supposed to read it, then the machine is secure. This concept is often called trust: you trust the system to preserve and protect your data.
By this definition, natural disasters and buggy software are as much threats to security as unauthorized users. This belief is obviously true from a practical standpoint. Whether your data is erased by a vengeful employee, a random virus, an unexpected bug, or a lightning strike - the data is still gone.
Our practical definition might also imply to some that security is concerned with issues of testing your software and hardware, and with preventing user mistakes. However, we don't intend our definition to be that inclusive. That's why the word "practical" is in the title of this book - and why we won't try to be more specific about defining what "security" is, exactly. A formal definition wouldn't necessarily help you any more than our working definition, and would require detailed explanations of risk assessment, asset valuation, policy formation, and a number of other topics beyond what we are able to present here.
On the other hand, knowing something about these concepts is important in the long run. If you don't know what you're protecting, why you're protecting it, and what you are protecting it from, your task will be rather difficult! Furthermore, you need to understand how to establish and apply uniform security policies. Much of that is beyond the scope of what we hope to present here; thus, we'll discuss a few of these topics in Chapter 2, Policies and Guidelines , Policies and Guidelines. We'll also recommend that you examine some of the references available. Several good introductory texts in this area, including Computer Security Basics (Russell and Gangemi), Computer Crime: A Crimefighter's Handbook (Seger, VonStorch, and Icove), and Control and Security of Computer Information Systems (Fites, Kratz, and Brebner) are listed in Appendix D, Paper Sources . Other texts, university courses, and professional organizations can provide you with more background. Security isn't a set of tricks, but an ongoing area of specialization.
This book emphasizes techniques to help keep your system safe from other people - including both insiders and outsiders, those bent on destruction, and those who are simply ignorant or untrained. The text does not detail every specific security-related feature that is available only on certain versions of UNIX from specific manufacturers: companies that take the time to develop such software usually deliver it with sufficient documentation.
Throughout this book, we will be presenting mechanisms and methods of using them. To decide which mechanisms are right for you, take a look at Chapter 2 . Remember, each site must develop its own overall security policies, and those policies will determine which mechanisms are appropriate to use. End users should also read Chapter 2 - users should be aware of policy considerations, too.
For example, if your local policy is that all users can build and install programs that can be accessed by other users, then you may wish to set the file permissions on /usr/local/bin to be mode 1777, which allows users to add their own files but does not generally allow them to delete files placed there by other users. If you don't wish to take the risk of allowing users to install publicly accessible programs that might contain Trojan horses or trap doors, a more appropriate file permissions setting for /usr/local/bin might be 755.