Postfix master running as root

Question

Does running /usr/lib/postfix/master as a root could cause a security threat ? A fresh installation, gives this :

root     11622  0.0  0.0   4792  1432 ?        Ss   19:11   0:00 /usr/lib/postfix/master
postfix  11624  0.0  0.0   4812  1324 ?        S    19:11   0:00 pickup -l -t unix -u -c
postfix  11625  0.0  0.0   4856  1344 ?        S    19:11   0:00 qmgr -l -t unix -u

Answer 1

The Postfix master process is the one that launches the other daemons. In particular, it launches the daemon that delivers mail locally; the latter must be able to impersonate any user ID in the system, which involves beginning its life as root. Thus, it is mostly unavoidable that the master process runs as root; otherwise, it would not work at all.

---

Moreover, the "risk" involved in running things as root is often overestimated. For instance, on my own server, what I fear most is that my machine would be subverted and used as a relay for attacking other people. Whether an attacker gains root access or only a "normal user" access does not change things much in that respect.

There is a widespread habit of turning root daemons into non-root daemons, and then to rejoice at the "security improvement". The improvement is real in the mainframe scenario, where many users have shell accounts on the same machine, and the attacker is one of these users, intent on gaining access to the files of other users. However, the mainframe model has mostly disappeared (it used to be prevalent in universities, but nowadays every student has his/her own computer to play with). When machines are "personal" (e.g. you have your own server and no hostile individual has an account on it), the benefits of running some daemons under a non-root UID are slight. It does not harm by itself, but it does not justify going out of your way in complex ways to "fix root daemons".

What makes Postfix daemons secure is absence of buffer overflows or similar vulnerabilities; running as non-root is simply a way to mitigate consequences in case a vulnerability was present and exploited by an attacker; and the mitigation does not gain much when the machine is not a shared mainframe.

Answer 2

A server that receives email and delivers it to local users needs root permissions for two things.

• The component that listens to incoming connections needs to bind the TCP ports for SMTP (25 without SSL, 465 with SSL), because port numbers below 1024 are reserved to administrator-controlled services and binding them is reserved to root (or processes with the applicable capability on e.g. Linux).
• The component that delivers email needs to be able to invoke a mail delivery agent, such as procmail or maildrop. These programs execute arbitrary code chosen by the user who receives the email, so they must be invoked by a program that can impersonate any user: the invoking program must run as root.

The part of Postfix that is concerned with sending email out doesn't need to run as root, and it doesn't run as root. The part that is concerned with receiving emails from remote machines runs as root because it needs to.

It is possible to run Postfix or other MTA entirely as a non-root user, but this comes with restrictions:

• The administrator must redirect incoming connections to the TCP port to a different port above 1024.
• Only remote forwarding and straight delivery to a mailbox file are possible, not the invocation of an MDA. Furthermore, local delivery requires that the mailbox files are writable by the delivery component; this can be achieved with group permissions.

Answer 3

It is always better to run only non-root processes.

Just as an example: In case when the postfix is not the only a single important application in your system, running it as root will only reduce work for an adversary as by getting into the postfix's master process (s)he will be able to get anywhere in your system (e.g. access to all FS, dumping other processes with sensitive information in them, all kinds of nasty things basically that a root user can do). Otherwise, (s)he will need to find/craft a privilege escalation exploit. Even with the postfix being a single application, it is much easier for an adversary to remove the logs / hide his presence in the system.

There is a way for a non-root process to bind ports below 1024:

$ cp -v $(which nc) .
'/bin/nc' -> './nc'

$ ./nc -v -l -p 1025

Listening on [0.0.0.0] (family 0, port 1025)
$ ./nc -v -l -p 25
nc: Permission denied

$ sudo setcap 'cap_net_bind_service=+ep' ./nc

$ ./nc -v -l -p 25
Listening on [0.0.0.0] (family 0, port 25)
Connection from localhost 39964 received!
test

For more information please on setcap, refer to https://stackoverflow.com/a/414258

Principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege

Answer 4

The reason the master process has to be started as root is because only root can bind to a port in the range of the first 1024 "privileged" ports.

Running any type of software as root could be considered a security thread but it also depends how secure the software itself is, and if updates/patches are applied regularly.

If you would like to add an extra layer of security you could consider the following:

1. Configure Postfix to listen on a port above 1024.
2. Run the Postfix master daemon as the user postfix.
3. Configure IP tables to forward TCP/25 to the configured TCP port in step 1.

Also consider this: Do you trust iptables more than Postfix from a security perspective?