1.4.1 Expectations

The biggest problem with improving UNIX security is arguably one of expectation. Many users have grown to expect UNIX to be configured in a particular way. Their experience with UNIX in academic and research settings has always been that they have access to most of the directories on the system and that they have access to most commands. Users are accustomed to making their files world-readable by default. Users are also often accustomed to being able to build and install their own software, often requiring system privileges to do so. The trend in "free" versions of UNIX for personal computer systems has amplified these expectations.

Unfortunately, all of these expectations are contrary to good security practice in the business place. To have stronger security, system administrators must often curtail access to files and commands that are not strictly needed for users to do their jobs. Thus, someone who needs email and a text processor for his work should not also expect to be able to run the network diagnostic programs and the C compiler. Likewise, to heighten security, users should not be able to install software that has not been examined and approved by a trained and authorized individual.

The tradition of open access is strong, and is one of the reasons that UNIX has been attractive to so many people. Some users argue that to restrict these kinds of access would make the systems something other than UNIX. Although these arguments may be valid, in instances where strong security is required, restrictive measures may be needed.

At the same time, administrators can strengthen security by applying some general security principles, in moderation. For instance, rather than removing all compilers and libraries from each machine, the tools can be protected so that only users in a certain user group can access them. Users with a need for such access, and who can be trusted to take due care, can be added to this group. Similar methods can be used with other classes of tools, too, such as network monitoring software or Usenet news programs.

Furthermore, changing the fundamental view of data on the system can be beneficial: from readable by default to unreadable by default. For instance, user files and directories should be protected against read access instead of being world-readable by default. Setting file access control values appropriately and using shadow password files are just two examples of how this simple change in system configuration can improve the overall security of UNIX.

The most critical aspect of enhancing UNIX security is that the users themselves participate in the alteration of their expectations. The best way to meet this goal is not by decree, but through education and motivation. Many users started using UNIX in an environment less threatening than they face today. By educating users of the dangers and how their cooperation can help to thwart those dangers, the security of the system is increased. By properly motivating the users to participate in good security practice, you make them part of the security mechanism. Better education and motivation work well only when applied together, however; education without motivation may not be applied, and motivation without education leaves gaping holes in what is done.

1.4.2 Software Quality

Much of the UNIX operating system and utilities that people take for granted was written as student projects, or as quick "hacks" by software developers inside research labs. These programs were not formally designed and tested: they were put together and debugged on the fly. The result is a large collection of tools that usually work, but sometimes fail in unexpected and spectacular ways. Utilities were not the only things written by students. Much of BSD UNIX, including the networking code, was written by students as research projects of one sort or another - and these efforts sometimes ignored existing standards and conventions.

This analysis is not intended to cast aspersions on the abilities of students, and instead points out that today's UNIX was not created as a carefully designed and tested system. Indeed, a considerable amount of the development of UNIX and its utilities occurred at a time when good software engineering tools and techniques were not yet developed or readily available.[7] The fact that occasional bugs are discovered that result in compromises of the security of the system is no wonder; the fact that so few bugs are evident is perhaps the real wonder!

[7] Some would argue that they are still not available. Few academic environments currently have access to modern software engineering tools because of their cost, and few vendors are willing to provide copies at prices that academic institutions can afford.

Unfortunately, two things are not occurring as a result of the discovery of faults in the existing code. The first is that software designers are not learning from past mistakes. For instance, buffer overruns (mostly resulting from fixed-length buffers and functions that do not check their arguments) have been recognized as a major UNIX problem area for some time, yet software continues to be discovered containing such bugs, and new software is written without consideration of these past problems. For instance, a fixed-length buffer overrun in the gets () library call was one of the major propagation modes of the Morris Internet worm of 1988, yet, as we were working on the second edition of this book in late 1995, news of yet another buffer-overrun security flaw surfaced - this time in the BSD-derived syslog() library call. It is inexcusable that vendors continue to ship software with these kinds of problems in place.

A more serious problem than any particular flaw is the fact that few, if any, vendors are performing an organized program of testing on the software they provide. Although many vendors test their software for compliance with industry "standards," few apparently test their software to see what it does when presented with unexpected data or conditions. With as much as 40% of the utilities on some machines being buggy,[8] one might think that vendors would be eager to test their versions of the software and to correct lurking bugs. However, as more than one vendor"s software engineer has told us, "The customers want their UNIX - including the flaws - exactly like every other implementation. Furthermore, it's not good business: customers will pay extra for performance, but not for better testing."

[8] See the reference to the paper by Barton Miller, et al., given in Appendix D.

As long as the customers demand strict conformance of behavior to existing versions of the programs, and as long as software quality is not made a fundamental purchase criterion by those same customers, vendors will most likely do very little to systematically test and fix their software. Formal standards, such as the ANSI C standard and POSIX standard help perpetuate and formalize these weaknesses, too. For instance, the ANSI C standard[9] perpetuates the gets() library call, forcing UNIX vendors to support the call, or to issue systems at a competitive disadvantage because they are not in compliance with the standard.[10]

[9] ANSI X3J11

[10] See Appendix D for references describing this scenario.

1.4.3 Add-On Functionality Breeds Problems

One final influence on UNIX security involves the way new functionality has been added over the years. UNIX is often cited for its flexibility and reuse characteristics; therefore, new functions are constantly built on top of UNIX platforms and eventually integrated into released versions. Unfortunately, the addition of new features is often done without understanding the assumptions that were made with the underlying mechanisms and without concern for the added complexity presented to the system operators and maintainers. Applying the same features and code in a heterogeneous computing environment can also lead to problems.

As a special case, consider how large-scale computer networks such as the Internet have dramatically changed the security ground rules from those under which UNIX was developed. UNIX was originally developed in an environment where computers did not connect to each other outside of the confines of a small room or research lab. Networks today interconnect tens of thousands of machines, and millions of users, on every continent in the world. For this reason, each of us confronts issues of computer security directly: a doctor in a major hospital might never imagine that a postal clerk on the other side of the world could pick the lock on her desk drawer to rummage around her files, yet this sort of thing happens on a regular basis to "virtual desk drawers" on the Internet.

Most colleges and many high schools now grant network access to all of their students as a matter of course. The number of primary schools with network access is also increasing, with initiatives in many U.S. states to put a networked computer in every classroom. Granting telephone network access to a larger number of people increases the chances of telephone abuse and fraud, the same as granting widespread computer network access increases the chances that the access will be used for illegitimate purposes. Unfortunately, the alternative of withholding access is equally unappealing. Imagine operating without a telephone because of the risk of receiving prank calls!

The foundations and traditions of UNIX network security, however, were profoundly shaped by the earlier, more restricted view of networks, and not by our more recent experiences. For instance, the concept of user IDs and group IDs controlling access to files was developed at a time when the typical UNIX machine was in a physically secure environment. On top of this was added remote manipulation commands such as rlogin and rcp that were designed to reuse the user-ID/group-ID paradigm with the concept of "trusted ports" for network connections. Within a local network in a closed lab, using only relatively slow computers, this design (usually) worked well. But now, with the proliferation of workstations and non-UNIX machines on international networks, this design, with its implicit assumptions about restricted access to the network, leads to major weaknesses in security.[11]

[11] Peter Salus notes in his fine history Casting the Net: From Arpanet to Internet and Beyond... (Addison-Wesley, 1995), that Bob Metcalf warned of these dangers in 1973, in RFC 602. That warning, and others like it, went largely unheeded.

Not all of these unsecure foundations were laid by UNIX developers. The IP protocol suite on which the Internet is based, was developed outside of UNIX initially, and it was developed without a sufficient concern for authentication and confidentiality. This lack of concern has enabled recent cases of password sniffing and IP sequence spoofing to occur, and make news, as "sophisticated" attacks.[12] (These attacks are discussed in Chapter 16, TCP/IP Networks.)

[12] To be fair, the designers of TCP/IP were aware of many of the problems. However, they were more concerned about making everything work so they did not address many of the problems in their design. The problems are really more the fault of people trying to build critical applications on an experimental set of protocols before the protocols were properly refined - a familiar problem.

Another facet of the problem has to do with the "improvements" made by each vendor. Rather than attempting to provide a unified, simple interface to system administration across platforms, each vendor has created a new set of commands and functions. In many cases, improvements to the command set have been available to the administrator. However, there are also now hundreds (perhaps thousands) of new commands, options, shells, permissions, and settings that the administrator of a heterogeneous computing environment must understand and remember. Additionally, many of the commands and options are similar to each other, but have different meanings depending on the environment in which they are used. The result can often be disaster when the poor administrator suffers momentary confusion about the system or has a small lapse in memory. This complexity further complicates the development of tools that are intended to provide cross-platform support and control. For a "standard" operating system, UNIX is one of the most nonstandard systems to administer.

That such difficulties arise is both a tribute to UNIX, and a condemnation. The robust nature of UNIX enables it to accept and support new applications by building on the old. However, existing mechanisms are sometimes completely inappropriate for the tasks assigned to them. Rather than being a condemnation of UNIX, such shortcomings are actually an indictment of the developers for failing to give more consideration to the human and functional ramifications of building on the existing foundation.

Here, then, is a conundrum: to rewrite large portions of UNIX and the protocols underlying its environment, or to fundamentally change its structure, would be to attack the very reasons UNIX has become so widely used. Furthermore, such restructuring would be contrary to the spirit of standardization that has been a major factor in the recent wide acceptance of UNIX. At the same time, without reevaluation and some restructuring, there is serious doubt about the level of trust that can be placed in the system. Ironically, the same spirit of development and change is what has led UNIX to its current niche.