Around the middle of 2025, I wrote a little code that allowed me to
run a Postfix master daemon as a non-root process. I used this to
run a trivial-rewrite daemon and test some new code.
Firing up a Postfix daemon this way is simpler than building a
disposable container with Postfix to run the test. While the test
was successful, this root-less master daemon support was never
merged or released.
* How it works: Root-less operation relies on LD_PRELOAD to intercept
system calls such as getuid() and setuid(), emulating the results
that a Postfix program expects.
Recently, someone's customer asked if there could be a way to run
Postfix without root privileges IN PRODUCTION. I offered to share
a preview of the 2025 code, with some documentation to explain its
limitations.
Security Trade-offs for Relay-Only Deployments
Normally, Postfix uses root privilege to build internal boundaries
within Postfix daemons. They run as root while accessing sensitive
resources, and irrevocably drop privileges before handling any
requests. Root-less Postfix daemons cannot build such boundaries.
Running root-less Postfix daemons as an SMTP or LMTP relay degrades
its defense-in-depth model. While Postfix becomes less secure than
it could be, it still is not worse than other MTAs.
* Security degradation details:
1) Loss of Isolation: The chroot capability is unavailable.
2) Asset Exposure: TLS private keys and maillog_file
logfiles are no longer root-only readable or writable.
In my opinion, if these losses are acceptable, then running root-less
Postfix as a relay-only deployment would be feasible.
Critical Risks for Full-Service Deployments
Normally, Postfix uses root privilege to build external boundaries
between Postfix daemons and other local system users. The local(8),
pipe(8), spawn(8) or virtual(8) daemons retain root privilege but
run as the "postfix" user most of the time, briefly impersonating
a target user when delivering a message to a file or when executing
non-Postfix code. Again, root-less Postfix daemons cannot build
such boundaries. Every deamon runs as "postfix" all the time.
The absence of external boundaries creates unacceptable problems
if you try to run any of the local(8), pipe(8), spawn(8) or virtual(8)
daemons. See https://www.postfix.org/UNPRIVILEGED_README.html for
context.
TL;DR: Local system users could read, modify, or delete any
message in the mail queue, as well as tamper with anyone's mail
during or after delivery. These vulnerabilities would also exist
if other MTAs were modified to run root-less.
The code is currently waiting to be merged into Postfix. The latest
version is postfix-3.12-20260831-nonprod-unprivileged.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
