UNIX System Administration Handbook - Evi Nemeth [360]
Permissions
File and directory permissions are very important to sendmail security. Use the settings listed in Table 19.16 to be safe.
Table 19.16 Owner and permissions for sendmail-related directories
sendmail will not read files that have lax permissions (for example, files that are group or world-writable or that live in group or world-writable directories). Some of sendmail’s rigor with regard to ownerships and permissions was motivated by operating systems that allow users to give their files away with chown (those derived from System V, mostly).25
In particular, sendmail is very picky about the complete path to any alias file or forward file. This pickiness sometimes clashes with the way sites like to manage Majordomo mailing list aliases. If the Majordomo list is in /usr/local, for example, the entire path must be trusted; no component can have group write permission. This constraint makes it more difficult for the list owner to manage the alias file. To see where you stand with respect to sendmail’s ideas about permissions, run
# sendmail -v -bi
The -bi flag initializes the alias database and warns you of inappropriate permissions.
sendmail will no longer read a .forward file that has a link count greater than 1 if the directory path to it is unsafe (has lax permissions). This rule bit Evi recently when her .forward file, which was typically a hard link to either .forward.to.boulder or .forward.to.sandiego, silently failed to forward her mail from a small site at which she did not receive much mail. It was months before she realized and understood that “I never got your mail” was her fault and not a valid excuse anymore.
You can turn off many of the restrictive file access policies mentioned above with the DontBlameSendmail option.
Safe mail to files and programs
We recommend that you use smrsh instead of /bin/sh as your program mailer and that you use mail.local instead of /bin/mail as your local mailer. See page 586 for more information. Both helper programs are included in the sendmail distribution. To incorporate them into your configuration, add the lines
FEATURE('smrsh', 'path-to-smrsh')
FEATURE('local_lmtp', 'path-to-mail.local')
to your .mc file. If you omit the explicit paths, they default to /usr/libexec/smrsh and /usr/libexec/mail.local.
smrsh will only execute the programs contained in one directory, /usr/adm/sm.bin by default.26
smrsh ignores user-specified paths and tries to find any requested commands in its own known-safe directory. smrsh also blocks the use of certain shell metacharacters such as “<“, the input redirection symbol. Symbolic links are allowed in sm.bin, so you don’t need to make duplicate copies of the programs you allow.
Here are some example shell commands and their possible smrsh interpretations:
vacation eric executes /usr/adm/sm.bin/vacation eric
cat /etc/passwd rejected, cat not in sm.bin
vacation eric < /etc/passwd rejected, no < allowed
sendmail’s SafeFileEnvironment option controls where files can be written when email is redirected to a file by an aliases or .forward file. It causes sendmail to execute a chroot system call, making the root of the filesystem no longer / but rather /safe, or whatever path you specified in the SafeFileEnvironment option. An alias that directed mail into the /etc/passwd file, for example, would really be written to /safe/etc/passwd.
The SafeFileEnvironment option also protects device files, directories, and other special files by allowing writes only to regular files. Besides increasing security, this option helps to ameliorate the effects of user mistakes. Some sites set the option to /home to allow access