Overall Sendmail Security

1.File and directory permissions

It is imperative that Sendmail's binaries and configuration files have appropriate permissions. Weak permissions on files and directories can easily result in system compromise. For instance:

Everyone who has write access to your sendmail.cf can use the program form of the F command combined with setting the DefaultUser to 0:0 to cause sendmail to execute an arbitrary script as root. If that script happens to make one of your installed shells (or a copy of a shell in /tmp, for instance) a setuid binary, anyone with local access can get root access.

Attackers may also exploit group-writable .forward and :include: files to gain system access as the file owner.

Protecting the aliases file alone is not sufficient as that is merely a source file to generate the alias database, a db3(3) format file called aliases.db in /etc/mail.

Improper directory ownership can result in root-owned files being overwritten or directory owners being replaced.

To help prevent these situations, sendmail will check the permissions of all sendmail-related binaries, configuration files, and directories on the system. You can force an audit with the following command:

% sudo sendmail -v -d44.4 -bv postmaster


Observe the output closely and ensure your system does not fall prey to weak permissions. Once you have solidified the desired permissions on your system, you may want to employ some combination of file immutability and permissions auditing software like Tripwire, Osiris, or mtree(8).

2.Beware recipient programs

Most sendmail configuration files, including .forward files, :include: mailing lists, aliases, and the sendmail.cf configuration file itself, support the execution of arbitrary programs. We mentioned earlier that .forward and :include: mailing list files are parsed and acted upon in the user context. If you've been diligent, these files will be writable only by the owner, ensuring that the execution of programs is intentional. If you've not been careful, users could easily start running programs as other users.

Still, just the fact that these files point to arbitrary programs means you've got another problem to deal with. All of these programs have suddenly become a part of your mail system, and you'll have to audit them, too. Be especially wary of the aliases file: sendmail will take actions on this file in the daemon user context.

You might want to consider restricting users from passing incoming mail to programs by ensuring their shell as specified in the passwd files is not in /etc/shells. You may still allow login by specifying a valid shell that is not in /etc/shells: you could, perhaps, create a /bin/allow-login shell, which is a copy of /bin/tcsh, and ensure /bin/allow-login is not listed in /etc/shells.