Postfix Overview - Introduction - SCN Research

Postfix Overview - Security
assistance from a set-uid or set-gid command or from a mail daemon process. The maildrop directory is not
used for mail coming in via the network, and queue files are not readable for other users.
A writable directory opens up opportunities for annoyance: a local user can make hard links to someone else's
maildrop files so they don't go away and/or are delivered multiple times; a local user can fill the maildrop
directory with garbage and try to make the mail system crash; and a local user can hard link someone else's files
into the maildrop directory and try to have them delivered as mail. However, Postfix queue files have a specific
format; less than one in 10^12 non-Postfix files would be recognized as a valid Postfix queue file.
If a world-writable maildrop directory is not acceptable, sites can revoke world write permission, and enable
set-gid privileges for a small helper program that is provided for this purpose.
Trust
As mentioned elsewhere in the overview, Postfix programs do not trust the contents of queue files or of the
Postfix internal IPC messages. Queue files have no on-disk record for deliveries to sensitive destinations such
as files or commands. Instead, programs such as the local delivery agent attempt to make security-sensitive
decisions on the basis of first-hand information.
Of course, Postfix programs do not trust data received from the network, either. In particular, Postfix filters
sender-provided data before exporting it via environment variables. If there is one lesson that people have
learned from Web site security disasters it is this one: don't let any data from the network near a shell. Filtering
is the best we can do.
Large inputs
• Memory for strings and buffers is allocated dynamically, in order to prevent buffer overrun problems.
• Long lines in message input are broken up into sequences of reasonably-sized chunks, and are
reconstructed upon delivery.
• Diagnostics are truncated (in one single place!) before they are passed to the syslog(3) interface, in order
to prevent buffer overruns on older platforms. However, no general attempt is made to truncate data
before it is passed to system calls or to library routines. On some platforms, the software may still exhibit
buffer overrun problems, due to vulnerabilities in the underlying software.
• No specific attempt is made to defend against unreasonably-long command-line arguments. UNIX
kernels impose their own limits, which should be sufficient to deal with runaway programs or with
malicious users.
Other defenses
• The number of in-memory instances of any object type is limited, to prevent the mail system from
becoming wedged under heavy load.
Page 2 of 2
• In case of problems, the software pauses before sending an error response to a client, before terminating
with a fatal error, or before attempting to restart a failed program. The purpose is to prevent runaway
conditions that only make problems worse.
Up one level | Introduction | Goals and features | Global architecture | Queue Management | Security
http://www.porcupine.org/postfix-mirror/security.html
6/26/01