Postfix: The Definitive Guide

chroot

Postfix provides multiple layers of security. One such layer is the option to permit most Postfix services to run within a chroot environment. The Unix chroot function allows a process to change its view of, and access to, its filesystem by changing its root directory to a new path other than the normal /.

The chroot feature is particularly beneficial for processes that must communicate with external, potentially hostile clients. If an attacker somehow manages to subvert the smtpd daemon, for example, the attacker gains only very limited access to the filesystem. Configuring for a chroot environment is an advanced Postfix feature that adds a layer of complexity that you or your administrators may not want to deal with. Generally, chroot is not needed, except for sites that use Postfix in a highly secure environment or on particularly exposed servers, such as dedicated firewall systems and bastion hosts.

All of the Postfix processes that use chroot change their root directory to the directory specified in the queue_directory parameter, which is normally /var/spool/postfix. When a process runs chrooted, the directory /var/spool/postfix/pid, for example, becomes /pid to that process, and the process cannot access any files other than those below its new root.

To chroot individual components, edit your master.cf file. Change the fifth column to y. The chroot option is possible with all components except the pipe, virtual, local, and proxymap services. In Example 4-1, chroot is enabled for the SMTP clients and server.

Since chroot changes the environment of the process, all of the resources the chrooted daemon needs must be available below the new root directory. Unfortunately, the specific resources Postfix daemons might need depend on your platform. In general, Postfix might require resources that provide user information (/etc/passwd), name resolution configuration (nsswitch.conf or resolv.conf), timezone information, or shared libraries. Some platforms also require certain device files. There are platform-specific scripts that come with the Postfix distribution. They’re available in the examples/chroot-setup/ subdirectory below the main distribution directory.

Executing the correct script should be sufficient to set up the chroot environment on your system. If there is not a script for your platform, you may have to experiment a little to find everything you need. Consider all of the resources mentioned above and review the example scripts for other platforms. Watch your logs for error messages after you chroot a process. An entry like the following:

postfix/smtp[1575]: fatal: unknown service: smtp/tcp

shows that Postfix cannot determine what port the smtp service uses. This problem is fixed by placing the /etc/services file into the chroot, by copying it to /var/spool/postfix/etc/services. Other symptoms show up in the log complaining of similar types of problems.

If the normal Postfix log doesn’t give enough information, you may have to run a trace to see where the program fails. Look for tools such as truss , strace, and tusc on your system. These tools can be used to see where a service fails when it tries to run in a chroot. If you discover the failure is due to a missing component, copy the component into the chrooted environment. See the DEBUG_README file that comes with Postfix for instructions on attaching tracing tools to Postfix.

Once you have Postfix running in a chroot, you need to make sure you keep your chroot resources in sync with the normal system files. If your chroot requires /etc/passwd, for example, whenever the system /etc/passwd changes, the chroot version must be updated, too. Creating link files doesn’t work because symlinks cannot cross the chroot boundary, and hard links do not work across filesystems.