Postfix Overview - Introduction - SCN Research

Postfix Overview - Security
Page 1 of 2
Postfix Overview - Security
Up one level | Introduction | Goals and features | Global architecture | Queue Management | Security
Introduction
By definition, mail software processes information from potentially untrusted sources. Therefore, mail software
must be written with great care, even when it runs with user privileges, and even when it does not talk directly
to a network.
Postfix is a complex system. The initial release has about 30,000 lines of code (after deleting the comments).
With a system that complex, the security of the system should not depend on a single mechanism. If it did, one
single error would be sufficient to compromise the entire mail system. Therefore, Postfix uses multiple layers of
defense to control the damage from software and other errors.
Least privilege
Most Postfix daemon programs can be run at fixed low privilege in a chrooted environment. This is especially
true for the programs that are exposed to the network: the SMTP server and SMTP client. Although chroot(2),
even when combined with low privilege, is no guarantee against system compromise it does add a considerable
hurdle. And we all know that every little bit helps.
Insulation
Postfix uses separate processes to insulate activities from each other. In particular, there is no direct path from
the network to the security-sensitive local delivery programs. An intruder first has to break through multiple
programs. Some parts of the Postfix system are multi-threaded. However, all programs that interact with the
outside world are single-threaded. Separate processes give better insulation than multiple threads within a
shared address space.
Controlled environment
No Postfix mail delivery program runs under control of a user process. Instead, most Postfix programs run
under control of a resident master daemon that runs in a controlled environment, without any parent-child
relationship to user processes. This approach eliminates exploits that involve signals, open files, environment
variables, and other process attributes that the UNIX system passes on from a possibly-malicious parent to a
child.
Set-uid
No Postfix program is set-uid. Introducing the concept was the biggest mistake made in UNIX history. Set-uid
(and its weaker cousin, set-gid) causes more trouble than it is worth. Each time a new feature is added to the
UNIX system, set-uid causes a security problem: shared libraries, the /proc file system, multi-language support,
to mention just a few examples. Set-uid makes it impossible to introduce some of the features that make UNIX
successors such as plan9 so attractive, for example, per-process file system name spaces.
By default, the maildrop queue directory is world-writable, so that local processes can submit mail without
http://www.porcupine.org/postfix-mirror/security.html
6/26/01