share/man/man7/sprog.7

   1 .\"
   2 .\" Copyright (c) 2001 Eric Melville <eric@FreeBSD.org>
   3 .\" All rights reserved.
   4 .\"
   5 .\" Redistribution and use in source and binary forms, with or without
   6 .\" modification, are permitted provided that the following conditions
   7 .\" are met:
   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.
  13 .\"
  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
  24 .\" SUCH DAMAGE.
  25 .\"
  26 .\" $FreeBSD$
  27 .\"
  28 .Dd June 3, 2001
  29 .Dt SPROG 7
  30 .Os
  31 .Sh NAME
  32 .Nm sprog
  33 .Nd secure programming practices
  34 .Sh DESCRIPTION
  35 Security issues have crept into many systems over the years.
  36 This document is a guide for programming practices that prevent these problems.
  37 .Ss Overview
  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.
  47 .Ss Buffer Overflows
  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.
  53 .Pp
  54 A good number of functions in the standard C library make it difficult or
  55 even impossible to prevent buffer overflows when used.
  56 These include
  57 .Xr fscanf 3 ,
  58 .Xr gets 3 ,
  59 .Xr getwd 3 ,
  60 .Xr realpath 3 ,
  61 .Xr scanf 3 ,
  62 .Xr sprintf 3 ,
  63 .Xr strcat 3 ,
  64 .Xr strcpy 3 ,
  65 .Xr vscanf 3 ,
  66 and
  67 .Xr vsprintf 3 .
  68 .Pp
  69 Many other functions that deal with strings can also open up a potential
  70 buffer overflow when not used carefully.
  71 For example,
  72 .Xr strncat 3
  73 does not go out of its way to provide
  74 .Tn NUL
  75 character termination.
  76 Of course, the proper length must always be specified.
  77 Usage of
  78 .Xr strlcat 3
  79 and
  80 .Xr strlcpy 3
  81 ensure that strings are null terminated and of the specified length.
  82 .Pp
  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
  87 .Ql %s .
  88 Always use the proper secure idiom:
  89 .Pp
  90 .Dl function("%s", string);
  91 .Pp
  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
  94 writing good code.
  95 .Ss Set-user-ID Issues
  96 In many cases, it may be necessary for a program to operate with an increased
  97 set of permissions.
  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
 102 possible.
 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
 106 .Xr setuid 2
 107 family of system calls.
 108 .Ss Limited Environments
 109 The traditional method of restricting a process is with the
 110 .Xr chroot 2
 111 system call.
 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
 116 .Xr chdir 2
 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
 119 obtained.
 120 .Pp
 121 Often,
 122 .Xr jail 2
 123 can be used to create a more complete and enclosed environment than
 124 .Xr chroot 2
 125 can provide.
 126 A jail limits all processes inside that environment, including processes with
 127 superuser privileges.
 128 .Pp
 129 Fine grained privileges, as described by
 130 .Tn POSIX Ns .1e
 131 extensions, are currently a work in progress, and the focus of the
 132 .Tn TrustedBSD
 133 Project.
 134 More information can be found at
 135 .Pa http://www.TrustedBSD.org/ .
 136 .Ss Trust
 137 Programs should not make assumptions about the environment in which they are
 138 running.
 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.
 147 .Ss Race Conditions
 148 A race condition is anomalous behavior caused by the relative timing of
 149 events.
 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
 152 file reads.
 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
 158 .Xr access 2
 159 and
 160 .Xr open 2 ,
 161 use
 162 .Xr seteuid 2
 163 and then call
 164 .Xr open 2
 165 directly.
 166 Set
 167 .Xr umask 2
 168 properly beforehand.
 169 .Sh SEE ALSO
 170 .Xr jail 2 ,
 171 .Xr setuid 2 ,
 172 .Xr strlcat 3 ,
 173 .Xr strlcpy 3
 174 .Sh AUTHORS
 175 .An -nosplit
 176 .An Eric Melville Aq eric@FreeBSD.org
 177 originally wrote this document based on a chapter of the
 178 .%B "FreeBSD Developer's Handbook"
 179 written by
 180 .An Murray Stokely Aq murray@FreeBSD.org .