Chapter 1. Background

Summary of Parts 1-4

As we turn to the most technical Part of the Handbook, it will be useful to review what we have already discussed in Parts 1-4. As you will recall,

Part 1 of this publication provided an introduction to the general issues of security in an electronic age. The section described the scope of IT security issues, explained some types of malicious behavior with respect to computers and networks, and outlined why security policies and procedures are essential for individuals and enterprises or all types.

Part 2 addressed the common concerns of individual users of computing and networking resources. It explained the key security issues that pertain to individual users and offered guidelines on techniques that, when properly employed, will minimize the threat of a security penetration.

Part 3 covered the administrative and policy aspects of security from an organizational point of view. Through opportunities presented by the new digital media, small and medium-sized enterprises (SMEs) in developing countries are moving into position to compete on a level playing field in the current expansion of the global markets. Good security policy and effective implementation of security procedures will minimize the risk of accidental and deliberate losses and provide the tools to identify attacks and to repair security breaches. In the SME context, security policy should also include elements such as an authentication policy for users of interactive application areas such as e-business, e-commerce, and e-government. This part makes suggestions on how solid security policies may be developed and deployed in a range of organizational environments.

Part 4 focuses on security issues and legislative initiatives that need to be understood and handled at the governmental level. In addition to securing its own information assets, a government has an obligation to set policy for securing and protecting the national information infrastructure. Governments also need to envision how the growth of the information infrastructure will impact its legal system. Part 4 outlines some of the key questions facing policy makers and leaders in the developing world and offers examples of policies from the international community that may serve as guidance for those people engaged with new regulatory efforts concerning cyberspace.

Summary of Part 5 with Note on Technical Background

Part 5 is aimed at helping system and network administrators perform their duties efficiently. It provides detailed information on security issues that need to be understood and addressed at a highly technical, including:

• classifying specific threats to security, including methods of attack that are used to penetrate systems and programs;

• monitoring critical systems and network traffic so that attempted intrusions can be detected and, when possible, rejected;

• assessing the results of security evaluations while policies and procedures are being developed and analyzing the results of logs and other ongoing documentation once those security measures have been implemented.

• handling a break-in, recovering from the security breach, and learning from the experience

Part 5 differs from the other four Parts of this Handbook in that it assumes a certain level of technical knowledge on behalf of the reader. While concepts have been explained clearly and examples given whenever possible, this section is designed for people with a fair amount of experience with (or at least very strong interest in) systems and their administration. There is a great deal of material to cover in this section and readers are strongly encouraged to make use of the Annexes which point to many respected references in the field of computer and network maintenance.

Since security issues often depend upon the operating environment of the computer, Part 5 provides subsections that address well-known security issues associated with the major operating systems in use today. Though the majority of Part 5 is system-independent whenever possible, pointers are offered on Microsoft Windows NT-based operating systems and Unix, Linux, MacOS X, and other variations of desktop Unix. In all cases, there are clear recommendations regarding the actions that can and should be taken to avoid compromise of system resources.

UNIX

There are several different (sometimes quite different) Unix or Unix-like operating systems, distributed by many different vendors. The reasons for this, and its implications, require a brief historical review.

The roots of Unix go back to the Multics project of the mid-1960s. The project, heavily funded by the U.S. Department of Defense Advanced Research Projects Agency (ARPA or DARPA) was designed to be a modular system built from banks of high-speed processors, memory, and communications equipment. By design, parts of the computer could be shut down for service without affecting other parts or the users. Although this level of processing is simply assumed today, such a capability was not available when Multics was begun. Multics was designed both to be resistant to external attacks and to protect the users on the system from each other – Multics was to support the concept of multilevel security. Multics eventually provided a level of security and service that is still unequaled by many of today’s computer systems.

Whereas Multics tried to do many things, Unix tried to do one thing well: run programs. Strong security was not part of this goal. The system was based on compact programs, called tools, each of which performed a single function. American Telephone and Telegraph (AT&T) added tools and features throughout the 1970’s. In 1973, Thompson rewrote most of Unix in Ritchie’s newly invented C programming language. C was designed to be a simple, portable language. Programs written in C could be moved easily from one kind of computer to another—as was the case with programs written in other high-level languages like FORTRAN—yet they ran nearly as fast as programs coded directly in a computer’s native machine language. By 1977, more than 500 sites were running the operating system; 125 sites were at universities in the United States and more than 10 foreign countries.

Development continued in different locations; including the University of California at Berkeley, which released the “Berkeley Software Distribution (BSD),” a collection of programs and modifications to the Unix system. Over the next six years, in an effort funded by ARPA, the so-called BSD Unix grew into an operating system of its own that offered significant improvements over AT&T’s. Perhaps the most important of the Berkeley improvements was in the area of networking, which made it easy to connect Unix computers to local area networks (LANs). For all of these reasons, the Berkeley version of Unix became very popular with the research and academic communities.

As Unix started to move from the technical to the commercial markets in the late 1980s, the conflict between operating system versions based on AT&T Unix and those based on BSD was beginning to cause problems for all vendors. Commercial customers wanted a standard version of Unix, hoping that it could cut training costs and guarantee software portability across computers made by different vendors. And the nascent Unix applications market wanted a standard version, believing that this would make it easier for them to support multiple platforms, as well as compete with the growing PC-based market.

In May 1988, seven of the industry’s Unix leaders—Apollo Computer, Digital Equipment Corporation, Hewlett- Packard, IBM, and three major European computer manufacturers —announced the formation of the Open Software Foundation (OSF). The goal of OSF was to wrest control of Unix away from AT&T alone and put it in the hands of a not-for-profit industry coalition, which would be chartered with shepherding the future development of Unix and making it available to all under uniform licensing terms. OSF decided to base its version of Unix on IBM’s implementation, then moved to the Mach kernel from Carnegie Mellon University, and an assortment of Unix libraries and utilities from HP, IBM, and Digital. Although the result of that effort was not widely adopted or embraced by all the participants, the OSF concept of generated further development activity.

GNU

Richard Stallman, a programmer with the MIT Artificial Intelligence Laboratory’s Lisp Machine Project, was tremendously upset when the companies that were founded to commercialize the research adopted rules prohibiting the free sharing of software. Stallman realized that if he wanted to have a large community of people sharing software, he couldn’t base it on specialty hardware manufactured by only a few companies and running only LISP. So instead, he decided to base a new software community on Unix, a powerful operating system that looked like it had a future. He called his project GNU, a recursive acronym meaning “GNU’s Not Unix!” To Stallman, being “free” wasn’t simply a measure of price, it was also a measure of freedom. Being free meant that he was free to inspect and make changes to the source code, and that he was free to share copies of the program with his friends. He wanted free software — as in free speech, not free beer. By 1985, GNU’s first major product, the Emacs text editor, had grown to the point that it could be readily used by people other than Stallman. Stallman next started working on a free C compiler, GNU C. Both of these programs were distributed under Stallman’s GNU General Public License (GPL). This license gave developers the right to distribute the source code and to make their own modifications, provided that all future modifications were released in source code form and under the same license restrictions. That same year, Stallman founded the Free Software Foundation, a non-profit foundation that solicited donations and used it to hire programmers who would write freely redistributable software.

Minix and Linux

At roughly the same time that Stallman started the GNU project, professor Andrew S. Tanenbaum decided to create his own implementation of the Unix operating system to be used in teaching and research. As all of the code would be original, he would be free to publish the source code in his textbook and distribute working operating systems without paying royalties to AT&T. The system, Minix, ran on IBM PC AT clones equipped with the Intel-based processors and was designed around them. The project resulted in a stable, well-documented software platform and an excellent operating system textbook. However, efficiency was not a design criteria for Minix, and coupled with the copyright issues associated with the textbook, Minix did not turn out to be a good choice for widespread, everyday use.

In 1991, a Finnish computer science student named Linus Torvalds decided to create a free version of the Unix operating system that would be better suited to everyday use. Starting with the Minix code set, Torvalds solely reimplemented the kernel and file system piece-by-piece until he had a new system that had none of Tanenbaum’s original code in it. Torvalds named the resulting system “Linux” and decided to license and distribute it under Stallman’s GPL. By combining his system with other freely available tools, notably the C compiler and editor developed by the Free Software Foundation’s GNU project and the X Consortium’s window server, Torvalds was able to create an entire working operating system. Work on Linux continues to this day by hundreds of contributors.

NetBSD, FreeBSD, and OpenBSD

In 1988 the Berkeley Computer Systems Research Group (CSRG) started on a project to eliminate all AT&T code from their operating system. First available in June 1989, Networking Release 1 consisted of Berkeley’s TCP/IP implementation and the related utilities. It was distributed on tape for a cost of $1,000, although anyone who purchased it could do anything that he wanted with the code, provided that the original copyright notice was preserved. Several large sites put the code up for anonymous FTP; the Berkeley code rapidly became the base of many TCP/IP implementations throughout the industry. An interim release named 4.3BSD-Reno occurred in early 1990; a second interim release, Networking Release 2, occurred in June 1991. This system was a complete operating system except for six remaining files in the kernel that contained AT&T code and had thus not been included in the operating system. In the fall of 1991, Bill Jolitz wrote those files for the Intel processor and created a working operating system called 386/BSD.

Within a few months a group of volunteers committed to maintaining and expanding the system formed and christened their effort “NetBSD.” The NetBSD project soon splintered. Some of the members decided that the project’s primary goal should support as many different platforms as possible and to continue to do operating system research. But another group of developers thought that they should devote their resources to making the system run as well as possible on the Intel 386 platform and making the system easier to use. This second group split off from the first and started the FreeBSD project. A few years later, a second splinter group broke off from the NetBSD project. This group decided that security and reliability were not getting the attention they should. The focus of this group was on careful review of the source code to identify potential problems. They restricted adoption of new code and drivers until they had been thoroughly vetted for quality. This third group adopted the name “OpenBSD.”

Businesses Adopt Unix

As a result of monopolistic pricing on the part of Microsoft and the security and elegance of the Unix operating systems, many businesses have developed a renewed interest in adopting a Unix base for some commercial products. A number of network appliance vendors found the stability and security of the OpenBSD platform to be appealing, and they adopted it for their projects. Other commercial users, especially many early web hosting firms, found the stability and support options offered by BSDI to be attractive, and they adopted BSD/OS. Several universities also adopted BSD/OS because of favorable licensing terms for students and faculty when coupled with the support options.

Meanwhile, Linux became extremely popular among individuals seeking an alternative OS for their PCs. Although OpenBSD was likely a more secure and stable operating system at the time, Linux provided support for a much larger base of hardware, and was somewhat easier to install and operate.

Another key influence in the mid-to-late 1990s occurred when researchers at various national laboratories, universities, and NASA began to experiment with cluster computing. With cluster computing, scores (or hundreds) of commodity PCs were purchased, placed in racks, and connected with high-speed networks. Instead of running one program really fast on one computer, big problems were broken into manageable chunks that were run in parallel on the racked PCs. This approach, although not appropriate for all problems, often worked better than using high-end supercomputers. Furthermore, it was often several orders of magnitude less costly. One of the first working systems of this type, named Beowulf, was based on Linux. Because of the code sharing and mutual development of the supercomputing community, Linux quickly spread to other groups around the world wishing to do similar work.

All of this interest, coupled with growing unease with Microsoft’s de facto monopoly of the desktop OS market, caught the attention of two companies — IBM and Dell — both of which announced commercial support for Linux. Around the same time, two companies devoted to the Linux operating system — Red Hat and VA Linux — had two of the most successful Initial Public Offerings in the history of the US stock market. Shortly thereafter, HP announced a supported version of Linux for their systems.

Today, many businesses and research laboratories run on Linux. They use Linux to run web servers, mail servers, and, to a lesser extent, as a general desktop computing platform. Instead of purchasing supercomputers, businesses create large Linux clusters that can solve large computing problems via parallel execution. FreeBSD, NetBSD, and OpenBSD are similarly well-suited to these applications, and are also widely used. However, based on anecdotal evidence, Linux appears to have a larger installed base of users than any one of the other systems. Based on announced commercial support, including ventures by Sun Microsystems, Linux seems better poised to grow in the marketplace. Nonetheless, because of issues of security and performance (at least), we do not expect the *BSD variants to fade from the scene; as long as the *BSD camps continue separate existences, however, it does seem unlikely that they will gain on Linux market share.

There are several versions of the Linux and BSD operating system that will boot off a single floppy. These versions, including Trinix, PicoBSD, and ClosedBSD, are designed for applications where high security is required, including forensics, recovery, and network appliances.

Security and Unix

Like Windows NT-based systems, Unix is a multi-user, multi-tasking operating system. Multi-user means that the operating system allows many different people to use the same computer at the same time. Multi-tasking means that each user can run many different programs simultaneously. One of the natural functions of such operating systems is to prevent different people (or programs) using the same computer from interfering with each other. Without such protection, a wayward program could affect other programs or other users, could accidentally delete files, or could even crash (halt) the entire computer system. To keep such disasters from happening, some form of computer security has always had a place in the Unix design philosophy.

Unix security provides more than mere memory protection. Unix has a sophisticated security system that controls the ways users access files, modify system databases, and use system resources. Unfortunately, those mechanisms don’t help much when the systems are misconfigured, are used carelessly, or contain buggy software. Nearly all of the security holes that have been found in Unix over the years have resulted from these kinds of problems rather than from shortcomings in the intrinsic design of the system. Thus, nearly all Unix vendors believe that they can (and perhaps do) provide a reasonably secure Unix operating system. We believe that Unix systems can be fundamentally more secure than other common operating systems. However, there are influences that work against better security in the Unix environment.

Expectations

The biggest problem with improving Unix security is arguably one of expectations. Many users have grown to expect Unix to be configured in a particular way. Their experience with Unix in academic, hobbyist, 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 may be 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.

Unfortunately, all of these expectations are contrary to good security practice. 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 e-mail 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.

Administrators can strengthen security by applying some general security principles, in moderation. For instance, rather than removing all compilers and libraries from each machine, these 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 (from readable by default to unreadable by default) can be beneficial. 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 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 to get users themselves to participate in the alteration of their expectations. Not surprisingly, this advice also applies to enhancing the security of NT-based systems when users are accustomed to Microsoft’s “personal” operating systems prior to NT. The best way to meet this goal is not by decree, but through education, awareness, and motivation. Technical security measures are crucial, but experience has proven repeatedly that people problems are not amenable to technological solutions. Many users started using computers in an environment that was less threatening than the one they face today. By educating users about the dangers and how their cooperation can help to thwart those dangers, the security of the system is increased. By properly motivating 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 mean that security measures are not actually applied, and motivation without education leaves gaping holes in what is done.