After the last several CERT advisories about sendmail, I decided to review the configuration that Avi Freedman and Mark Thomas developed for Net Access's mail configuration. The basic idea is to not run sendmail setuid to root. However, the sendmail documentation warns:
If you don't make sendmail setuid to root, it will still run but you lose a lot of functionality and a lot of privacy, since you'll have to make the queue directory world readable. You could also make sendmail setuid to some pseudo-user (e.g., create a user called "sendmail" and make sendmail setuid to that) which will fix the privacy problems but not the functionality issues. Also, this isn't a guarantee of security: for example, root occasionally sends mail, and the daemon often runs as root.
I disagree. I think it's possible to overcome both the security and the privacy concerns without giving sendmail any more privilege than setgid to mail. Here is my analysis of how to avoid loss of functionality and privacy with a setgid to mail sendmail.
Here is how I install sendmail under Linux (Debian and Red Hat):
# chown root.mail /usr/sbin/sendmail # chmod 2755 /usr/sbin/sendmail # chown mail.mail /var/spool/mqueue # chmod 770 /var/spool/mqueue # ls -ld /usr/sbin/sendmail /var/spool/mqueue -rwxr-sr-x 1 root mail 238232 Sep 20 00:29 /usr/sbin/sendmail drwxrwx--- 2 mail mail 1024 Nov 20 10:45 /var/spool/mqueue # ls -l /usr/bin/procmail -rwsr-sr-x 1 root mail 59385 Jan 18 1996 /usr/bin/procmail
Privacy is preserved by making sendmail setgid to mail and giving the group mail write permission to /var/spool/mqueue. The only loss of functionality that I have found concerns .forward files. The only case in which they might not work properly is when a local user sends mail to another local user. When the mail comes from another machine to port 25, the sendmail running on port 25 (since it was started by root herself) has no problem with .forward files and changing the efective uid to the user for running scripts in the .forward file and reading them from read protected home directories. One way to overcome a setgid to mail sendmail's .forward limitation is to configure the local sendmail to forward all mail to another host for delivery (using DH in sendmail.cf). I haven't tested this solution. In a public post on comp.mail.sendmail, Doug Siebert said that it works at his installation, but there are problems when the hub mail server is temporarily unavailable and mail is spooled locally. Another solution is to use procmail for local mail delivery. Then users can use .procmailrc instead of .forward. Procmail offers greater functionality than .forward anyway. So other than the break with the tradition of a filename called ".forward" and its traditional syntax, this is another fine option. Actually, the problem Doug Siebert noted occurs even in this case since when local shell users send mail to domains that are down, the mail will often be spooled locally. Hence (following Doug's recommendation) one should run sendmail from cron to process the spool. I developed this script for this purpose:
#!/bin/sh
PIDFILE="/var/run/$(basename $0)"
if [ -f "$PIDFILE" ]; then
exit 0
fi
cleanup() { rm -f $PIDFILE }
echo $$ > $PIDFILE; chmod 644 $PIDFILE
trap "cleanup" 15
cd /var/spool/mqueue && chmod --silent 600 * && chown root.root *
/usr/sbin/sendmail -q
cleanup
This is the solution I'm using on two production networks. It is working without problems.