2 .\" Copyright (c) 2001 Eric Melville <eric@FreeBSD.org>
3 .\" All rights reserved.
5 .\" Redistribution and use in source and binary forms, with or without
6 .\" modification, are permitted provided that the following conditions
8 .\" 1. Redistributions of source code must retain the above copyright
9 .\" notice, this list of conditions and the following disclaimer.
10 .\" 2. Redistributions in binary form must reproduce the above copyright
11 .\" notice, this list of conditions and the following disclaimer in the
12 .\" documentation and/or other materials provided with the distribution.
14 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
15 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
16 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
17 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
18 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
19 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
20 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
21 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
22 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
23 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
33 .Nd secure programming practices
35 Security issues have crept into many systems over the years.
36 This document is a guide for programming practices that prevent these problems.
38 Writing secure applications takes a very scrutinous and pessimistic outlook.
39 Applications should be run with the principle of
40 .Dq Li least privilege
41 so that no process is ever running with more than the bare minimum access it
42 needs to accomplish its function.
43 Previously tested code should be reused whenever possible.
44 Generally, anything beyond the control of a program should never be trusted.
45 This includes all forms of user input, system resources, interprocess
46 communication, and the timing of events.
48 One of the most common types of security problems is the buffer overflow.
49 In short, if a program is not careful with the data it receives, it may be
50 possible for this data to be written across memory, overwriting the return
51 address for a function call, and the program will be forced to run code that
52 does unfriendly things.
54 A good number of functions in the standard C library make it difficult or
55 even impossible to prevent buffer overflows when used.
69 Many other functions that deal with strings can also open up a potential
70 buffer overflow when not used carefully.
73 does not go out of its way to provide
75 character termination.
76 Of course, the proper length must always be specified.
81 ensure that strings are null terminated and of the specified length.
83 Functions that receive a string format must also be used carefully.
84 It is possible for a string to contain additional format specifiers, which
85 open up another possibility for a buffer overflow.
86 Never pass a string with untrusted data without using
88 Always use the proper secure idiom:
90 .Dl function("%s", string);
92 There are mechanisms that provide a backstop for these problems at the
93 library and compiler levels, however, there is no substitute for simply
95 .Ss Set-user-ID Issues
96 In many cases, it may be necessary for a program to operate with an increased
98 Reasons for this include binding to protected sockets, reading and writing
99 certain files and directories, and access to various resources.
100 Using a setuid program is frequently the solution.
101 However, it is important that programs give up these privileges as soon as
103 For example, if a program is binding to a protected socket, it should give
104 up its privileges as soon as it has finished binding to that socket.
105 This is accomplished with the
107 family of system calls.
108 .Ss Limited Environments
109 The traditional method of restricting a process is with the
112 This system call changes the root directory from which all other paths are
113 referenced for a process and any child processes.
114 Of course, the process must have access to this path to begin with.
115 The new environment does not actually take effect until
117 is called to place the process into the new environment.
118 Unfortunately, a process can break out of this environment if root access is
123 can be used to create a more complete and enclosed environment than
126 A jail limits all processes inside that environment, including processes with
127 superuser privileges.
129 Fine grained privileges, as described by
131 extensions, are currently a work in progress, and the focus of the
134 More information can be found at
135 .Pa http://www.TrustedBSD.org/ .
137 Programs should not make assumptions about the environment in which they are
139 This includes user input, signals, environment variables, system resources,
140 interprocess communications, and shared memory, amongst other things that are
141 beyond the control of the program.
142 They should not assume that all forms of invalid data can be detected either.
143 Instead, they should use positive filtering, and only allow a specific subset
144 of inputs that are known to be safe.
145 This is the same logic that an administrator should apply to a firewall, that
146 is, deny by default and specify what is to be accepted.
148 A race condition is anomalous behavior caused by the relative timing of
150 Programs should not assume that a particular event will occur before another.
151 The most common causes of race conditions are signals, access checks, and
153 Signals are asynchronous by nature, so special care must be taken
154 while dealing with them.
155 Attempting to check access with sequential non-atomic operations is a very
156 bad idea, as files can be moved and changed at any given time.
157 Instead of using a sequence of
176 .An Eric Melville Aq Mt eric@FreeBSD.org
177 originally wrote this document based on a chapter of the
178 .%B "FreeBSD Developer's Handbook"
180 .An Murray Stokely Aq Mt murray@FreeBSD.org .