Chapter 1. Introduction

This book describes a set of design and implementation guidelines for writing secure programs on Linux and Unix systems. For purposes of this book, a ``secure program'' is a program that sits on a security boundary, taking input from a source that does not have the same access rights as the program. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs. This book does not address modifying the operating system kernel itself, although many of the principles discussed here do apply. These guidelines were developed as a survey of ``lessons learned'' from various sources on how to create such programs (along with additional observations by the author), reorganized into a set of larger principles. This book includes specific guidance for a number of languages, including C, C++, Java, Perl, Python, TCL, and Ada95.

This book does not cover assurance measures, software engineering processes, and quality assurance approaches, which are important but widely discussed elsewhere. Such measures include testing, peer review, configuration management, and formal methods. Documents specifically identifying sets of development assurance measures for security issues include the Common Criteria [CC 1999] and the System Security Engineering Capability Maturity Model [SSE-CMM 1999]. More general sets of software engineering methods or processes are defined in documents such as the Software Engineering Institute's Capability Maturity Model for Software (SE-CMM), ISO 9000 (along with ISO 9001 and ISO 9001-3), and ISO 12207.

This book does not discuss how to configure a system (or network) to be secure in a given environment. This is clearly necessary for secure use of a given program, but a great many other documents discuss secure configurations. An excellent general book on configuring Unix-like systems to be secure is Garfinkel [1996]. Other books for securing Unix-like systems include Anonymous [1998]. You can also find information on configuring Unix-like systems at web sites such as http://www.unixtools.com/security.html. Information on configuring a Linux system to be secure is available in a wide variety of documents including Fenzi [1999], Seifried [1999], Wreski [1998], Swan [2001], and Anonymous [1999]. For Linux systems (and eventually other Unix-like systems), you may want to examine the Bastille Hardening System, which attempts to ``harden'' or ``tighten'' the Linux operating system. You can learn more about Bastille at http://www.bastille-linux.org; it is available for free under the General Public License (GPL).

This book assumes that the reader understands computer security issues in general, the general security model of Unix-like systems, and the C programming language. This book does include some information about the Linux and Unix programming model for security.

This book covers all Unix-like systems, including Linux and the various strains of Unix, and it particularly stresses Linux and provides details about Linux specifically. There are several reasons for this, but a simple reason is popularity. According to a 1999 survey by IDC, significantly more servers (counting both Internet and intranet servers) were installed in 1999 with Linux than with all Unix operating system types combined (25% for Linux versus 15% for all Unix system types combined; note that Windows NT came in with 38% compared to the 40% of all Unix-like servers) [Shankland 2000]. A survey by Zoebelein in April 1999 found that, of the total number of servers deployed on the Internet in 1999 (running at least ftp, news, or http (WWW)), the majority were running Linux (28.5%), with others trailing (24.4% for all Windows 95/98/NT combined, 17.7% for Solaris or SunOS, 15% for the BSD family, and 5.3% for IRIX). Advocates will notice that the majority of servers on the Internet (around 66%) were running Unix-like systems, while only around 24% ran a Microsoft Windows variant. Finally, the original version of this book only discussed Linux, so although its scope has expanded, the Linux information is still noticeably dominant. If you know relevant information not already included here, please let me know.

You can find the master copy of this book at http://www.dwheeler.com/secure-programs. This book is also part of the Linux Documentation Project (LDP) at http://www.linuxdoc.org It's also mirrored in several other places. Please note that these mirrors, including the LDP copy and/or the copy in your distribution, may be older than the master copy. I'd like to hear comments on this book, but please do not send comments until you've checked to make sure that your comment is valid for the latest version.

This book is copyright (C) 1999-2001 David A. Wheeler and is covered by the GNU Free Documentation License (GFDL); see Appendix C and Appendix D for more information.

Chapter 2 discusses the background of Unix, Linux, and security. Chapter 3 describes the general Unix and Linux security model, giving an overview of the security attributes and operations of processes, filesystem objects, and so on. This is followed by the meat of this book, a set of design and implementation guidelines for developing applications on Linux and Unix systems. The book ends with conclusions in Chapter 11, followed by a lengthy bibliography and appendices.

The design and implementation guidelines are divided into categories which I believe emphasize the programmer's viewpoint. Programs accept inputs, process data, call out to other resources, and produce output, as shown in Figure 1-1; notionally all security guidelines fit into one of these categories. I've subdivided ``process data'' into structuring program internals and approach, avoiding buffer overflows (which in some cases can also be considered an input issue), language-specific information, and special topics. The chapters are ordered to make the material easier to follow. Thus, the book chapters giving guidelines discuss validating all input (Chapter 4), avoiding buffer overflows (Chapter 5), structuring program internals and approach (Chapter 6), carefully calling out to other resources (Chapter 7), judiciously sending information back (Chapter 8), language-specific information (Chapter 9), and finally information on special topics such as how to acquire random numbers (Chapter 10).