postfix-master/security.html

   1 <html>
   2
   3 <head>
   4
   5 <title>Postfix Overview - Security</title>
   6
   7 <META NAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW">
   8 </head>
   9
  10 <body background="obsolete.gif">
  11
  12 <h1><a href="big-picture.html"><img src="small-picture.gif" width="115" height="45"></a> Postfix
  13 Overview - Security</h1>
  14
  15 <hr>
  16
  17 <p> <strong> Note: this web page is no longer maintained. It exists
  18 only to avoid breaking links in web pages that describe earlier
  19 versions of the Postfix mail system. </strong> </p>
  20
  21 <a href="docs.html">Up one level</a> | <a
  22 href="motivation.html">Introduction</a> | <a href="goals.html">Goals
  23 and features</a> | <a href="architecture.html">Global architecture</a>
  24 | <a href="queuing.html">Queue Management</a> | Security
  25
  26 <h2>Introduction</h2>
  27
  28 By definition, mail software processes information from potentially
  29 untrusted sources. Therefore, mail software must be written with
  30 great care, even when it runs with user privileges, and even when
  31 it does not talk directly to a network.
  32
  33 <p>
  34
  35 Postfix is a complex system. The initial release has about 30,000
  36 lines of code (after deleting the comments).  With a system that
  37 complex, the security of the system should not depend on a single
  38 mechanism. If it did, one single error would be sufficient to
  39 compromise the entire mail system.  Therefore, Postfix uses multiple
  40 layers of defense to control the damage from software and other
  41 errors.
  42
  43 <h2>Least privilege</h2>
  44
  45 Most Postfix daemon programs can be run at fixed low privilege in
  46 a chrooted environment. This is especially true for the programs
  47 that are exposed to the network: the SMTP server and SMTP client.
  48 Although chroot(2), even when combined with low privilege, is no
  49 guarantee against system compromise it does add a considerable
  50 hurdle.  And we all know that every little bit helps.
  51
  52 <h2>Insulation</h2>
  53
  54 Postfix uses separate processes to insulate activities from each
  55 other. In particular, there is no direct path from the network to
  56 the security-sensitive local delivery programs. An intruder first
  57 has to break through multiple programs. Some parts of the Postfix
  58 system are multi-threaded. However, all programs that interact with
  59 the outside world are single-threaded. Separate processes give
  60 better insulation than multiple threads within a shared address
  61 space.
  62
  63 <h2>Controlled environment</h2>
  64
  65 No Postfix mail delivery program runs under control of a user
  66 process. Instead, most Postfix programs run under control of a
  67 resident master daemon that runs in a controlled environment,
  68 without any parent-child relationship to user processes.  This
  69 approach eliminates exploits that involve signals, open files,
  70 environment variables, and other process attributes that the UNIX
  71 system passes on from a possibly-malicious parent to a child.
  72
  73 <h2>Set-uid</h2>
  74
  75 No Postfix program is <b>set-uid</b>. Introducing the concept was
  76 the biggest mistake made in UNIX history. <b>Set-uid</b> (and its
  77 weaker cousin, <b>set-gid</b>) causes more trouble than it is worth.
  78 Each time a new feature is added to the UNIX system, <b>set-uid</b>
  79 causes a security problem: shared libraries, the <b>/proc</b> file
  80 system, multi-language support, to mention just a few examples.
  81 <b>Set-uid</b> makes it impossible to introduce some of the features
  82 that make UNIX successors such as plan9 so attractive, for example,
  83 per-process file system name spaces.
  84
  85 <p>
  86
  87 Initially, the <b>maildrop</b> queue directory was world-writable,
  88 so that local processes could submit mail without assistance from
  89 a set-uid or set-gid command or from a mail daemon process.  The
  90 maildrop directory was not used for mail coming in via the network,
  91 and its queue files were not readable for unprivileged users.
  92
  93 <p>
  94
  95 A writable directory opens up opportunities for annoyance:  a local
  96 user can make hard links to someone else's maildrop files so they
  97 don't go away and/or are delivered multiple times; a local user
  98 can fill the maildrop directory with garbage and try to make the
  99 mail system crash; and a local user can hard link someone else's
 100 files into the maildrop directory and try to have them delivered
 101 as mail.  However, Postfix queue files have a specific format; less
 102 than one in 10^12 non-Postfix files would be recognized as a valid
 103 Postfix queue file.
 104
 105 <p>
 106
 107 Because of the potential for misbehavior, Postfix has abandoned
 108 the world-writable <b>maildrop</b> directory, and uses a small
 109 set-gid <b>postdrop</b> helper program for mail submission.
 110
 111 <h2>Trust</h2>
 112
 113 As mentioned elsewhere in the overview, Postfix programs do not
 114 trust the contents of queue files or of the Postfix internal IPC
 115 messages.  Queue files have no on-disk record for deliveries to
 116 sensitive destinations such as files or commands.  Instead, programs
 117 such as the local delivery agent attempt to make security-sensitive
 118 decisions on the basis of first-hand information.
 119
 120 <p>
 121
 122 Of course, Postfix programs do not trust data received from the
 123 network, either.  In particular, Postfix filters sender-provided
 124 data before exporting it via environment variables. If there is one
 125 lesson that people have learned from Web site security disasters
 126 it is this one:  <i> don't let any data from the network near a
 127 shell</i>. Filtering is the best we can do.
 128
 129 <h2>Large inputs</h2>
 130
 131 <ul>
 132
 133 <li>Memory for strings and buffers is allocated dynamically, in
 134 order to prevent buffer overrun problems.
 135
 136 <p>
 137
 138 <li>Long lines in message input are broken up into sequences of
 139 reasonably-sized chunks, and are reconstructed upon delivery.
 140
 141 <p>
 142
 143 <li>Diagnostics are truncated (in one single place!) before they
 144 are passed to the syslog(3) interface, in order to prevent buffer
 145 overruns on older platforms.  However, no general attempt is made
 146 to truncate data before it is passed to system calls or to library
 147 routines. On some platforms, the software may still exhibit buffer
 148 overrun problems, due to vulnerabilities in the underlying software.
 149
 150 <p>
 151
 152 <li>No specific attempt is made to defend against unreasonably-long
 153 command-line arguments. UNIX kernels impose their own limits, which
 154 should be sufficient to deal with runaway programs or with malicious
 155 users.
 156
 157 </ul>
 158
 159 <h2>Other defenses</h2>
 160
 161 <ul>
 162
 163 <li>The number of in-memory instances of any object type is limited,
 164 to prevent the mail system from becoming wedged under heavy load.
 165
 166 <p>
 167
 168 <li>In case of problems, the software pauses before sending an
 169 error response to a client, before terminating with a fatal error,
 170 or before attempting to restart a failed program. The purpose is
 171 to prevent runaway conditions that only make problems worse.
 172
 173 </ul>
 174
 175 <hr>
 176
 177 <a href="docs.html">Up one level</a> | <a
 178 href="motivation.html">Introduction</a> | <a href="goals.html">Goals
 179 and features</a> | <a href="architecture.html">Global architecture</a>
 180 | <a href="queuing.html">Queue Management</a> | Security
 181
 182 </body>
 183
 184 </html>