A wise man attacks the city of the mighty and pulls down the stronghold in which they trust. Proverbs 21:22 (NIV)
This paper describes a set of design and implementation guidelines for writing secure programs on Linux and Unix systems. For purposes of this paper, 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, CGI scripts, network servers, and setuid/setgid programs. This paper 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 paper 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 paper 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. For example, information on configuring a Linux system to be secure is available in a wide variety of documents including Fenzi [1999], Seifried [1999], and Wreski [1998].
This paper assumes that the reader understands computer security issues in general, the general security model of Unix-like systems, and the C programming language. This paper does include some information about the Linux and Unix programming model for security.
While this paper covers all Unix-like systems, including Linux and the various strains of Unix, it particularly stresses Linux and provides details about Linux specifically. There are several reasons for this. One simple reason is popularity: according to one survey, in 1999 significantly more servers were installed with Linux than with all Unix operating system types combined (25% for Linux versus 15% for all Unix system types combined) [Shankland 2000]. Also, the original version of this document only discussed Linux, so although its scope has expanded, the Linux information is still noticeably dominant. If you identify areas where this can be improved, please let me know.
You can find the master copy of this document at http://www.dwheeler.com/secure-programs. This document 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 document, but please do not send comments until you've checked to make sure that your comment is valid for the latest version.
This document is (C) 1999-2000 David A. Wheeler and is covered by the GNU General Public License (GPL); see the last section for more information.
This paper first discusses the background of Unix, Linux, and security. The next section 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 paper, a set of design and implementation guidelines for developing applications on Linux and Unix systems. This is broken into validating all input, avoiding buffer overflows, structuring program internals and approach, carefully calling out to other resources, judiciously sending information back, and finally information on special topics (such as how to acquire random numbers). The paper ends with conclusions and references.