source: trunk/third/sendmail/sendmail/SECURITY @ 19204

# Copyright (c) 2000-2002 Sendmail, Inc. and its suppliers.
#       All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#       $Id: SECURITY,v 1.1.1.1 2003-04-08 15:08:11 zacheiss Exp $
#

This file gives some hints how to configure and run sendmail for
people who are very security conscious (you should be...).

Even though sendmail goes through great lengths to assure that it
can't be compromised even if the system it is running on is
incorrectly or insecurely configured, it can't work around everything.
This has been demonstrated by recent OS problems which have
subsequently been used to compromise the root account using sendmail
as a vector.  One way to minimize the possibility of such problems
is to install sendmail without set-user-ID root, which avoids local
exploits.  This configuration, which is the default starting with
8.12, is described in the first section of this security guide.


*****************************************************
** sendmail configuration without set-user-ID root **
*****************************************************

sendmail needs to run as root for several purposes:

- bind to port 25
- call the local delivery agent (LDA) as root (or other user) if the LDA
  isn't set-user-ID root (unless some other method of storing e-mail in
  local mailboxes is used).
- read .forward files
- write e-mail submitted via the command line to the queue directory.

Only the last item requires a set-user-ID/set-group-ID program to
avoid problems with a world-writable directory.  It is however
sufficient to have a set-group-ID program and a group-writable
queue directory.  The other requirements listed above can be
fulfilled by a sendmail daemon that is started by root.  Hence this
section explains how to use two sendmail configurations to accomplish
the goal to have a sendmail binary that is not set-user-ID root,
and hence is not open to system configuration/OS problems or at
least less problematic in presence of those.

The default configuration starting with sendmail 8.12 uses one
sendmail binary which acts differently based on operation mode and
supplied options.

sendmail must be a set-group-ID (default group: smmsp, recommended
gid: 25) program to allow for queueing mail in a group-writable
directory.  Two .cf files are required:  sendmail.cf for the daemon
and submit.cf for the submission program.  The following permissions
should be used:

-r-xr-sr-x      root   smmsp    ... /PATH/TO/sendmail
drwxrwx---      smmsp  smmsp    ... /var/spool/clientmqueue
drwx------      root   wheel    ... /var/spool/mqueue
-r--r--r--      root   wheel    ... /etc/mail/sendmail.cf
-r--r--r--      root   wheel    ... /etc/mail/submit.cf

[Notice: On some OS "wheel" is not used but "bin" or "root" instead,
however, this is not important here.]

That is, the owner of sendmail is root, the group is smmsp, and
the binary is set-group-ID.  The client mail queue is owned by
smmsp with group smmsp and is group writable.  The client mail
queue directory must be writable by smmsp, but it must not be
accessible for others. That is, do not use world read or execute
permissions.  In submit.cf the option UseMSP must be set, and
QueueFileMode must be set to 0660.  submit.cf is available in
cf/cf/, which has been built from cf/cf/submit.mc.  The file can
be used as-is, if you want to add more options, use cf/cf/submit.mc
as starting point and read cf/README:  MESSAGE SUBMISSION PROGRAM
carefully.

The .cf file is chosen based on the operation mode.  For -bm (default),
-bs, and -t it is submit.cf (if it exists) for all others it is
sendmail.cf.  This selection can be changed by -Ac or -Am (alternative
.cf file: client or mta).

The daemon must be started by root as usual, e.g.,

/PATH/TO/sendmail -L sm-mta -bd -q1h

(replace /PATH/TO with the right path for your OS, e.g.,
/usr/sbin or /usr/lib).

Notice: if you run sendmail from inetd (which in general is not a
good idea), you must specify -Am in addition to -bs.

Mail will end up in the client queue if the daemon doesn't accept
connections or if an address is temporarily not resolvable.  The
latter problem can be minimized by using

        FEATURE(`nocanonify', `canonify_hosts')
        define(`confDIRECT_SUBMISSION_MODIFIERS', `C')

which, however, may have undesired side effects.  See cf/README for
a discussion.  In general it is necessary to clean the queue either
via a cronjob or by running a daemon, e.g.,

/PATH/TO/sendmail -L sm-msp-queue -Ac -q30m

If the option UseMSP is not set, sendmail will complain during
queue runs about bogus file permission.  If you want a queue runner
for the client queue, you probably have to change OS specific
scripts to accomplish this (check the man pages of your OS for more
information.)  You can start this program as root, it will change
its user id to RunAsUser (smmsp by default, recommended uid: 25).
This way smmsp does not need a valid shell.

Summary
-------

This is a brief summary how the two configuration files are used:

sendmail.cf     For the MTA (mail transmission agent)
        The MTA is started by root as daemon:

                /PATH/TO/sendmail -L sm-mta -bd -q1h

        it accepts SMTP connections (on ports 25 and 587 by default);
        it runs the main queue (/var/spool/mqueue by default).

submit.cf       For the MSP (mail submission program)
        The MSP is used to submit e-mails, hence it is invoked
        by programs (and maybe users); it does not run as SMTP
        daemon; it uses /var/spool/clientmqueue by default; it
        can be started to run that queue periodically:

                /PATH/TO/sendmail -L sm-msp-queue -Ac -q30m


Hints and Troubleshooting
-------------------------

RunAsUser: FEATURE(`msp') sets the option RunAsUser to smmsp.
This user must have the group smmsp, i.e., the same group as the
clientmqueue directory.  If you specify a user whose primary group
is not the same as that of the clientmqueue directory, then you
should explicitly set the group, e.g.,

        FEATURE(`msp')
        define(`confRUN_AS_USER', `mailmsp:smmsp')

STARTTLS: If sendmail is compiled with STARTTLS support on a platform
that does not have HASURANDOMDEV defined, you either need to specify
the RandFile option (as for the MTA), or you have to turn off
STARTTLS in the MSP, e.g.,

        DAEMON_OPTIONS(`Name=NoMTA, Addr=127.0.0.1, M=S')
        FEATURE(`msp')
        CLIENT_OPTIONS(`Family=inet, Address=0.0.0.0, M=S')

The first option is used to turn off STARTTLS when the MSP is
invoked with -bs as some MUAs do.


What doesn't work anymore
-------------------------

Normal users can't use mailq anymore to see the MTA mail queue.
There are several ways around it, e.g., changing QueueFileMode
or giving users access via a program like sudo.

sendmail -bv may give misleading output for normal users since it
may not be able to access certain files, e.g., .forward files of
other users.


Alternative
-----------

Instead of having one set-group-ID binary, it is possible to use
two with different permissions: one for message submission
(set-group-ID), one acting as daemon etc, which is only executable
by root.  In that case it is possible to remove features from
the message submission program to have a smaller binary.
You can use

        sh ./Build install-sm-mta

to install a sendmail program to act as daemon etc under the name
sm-mta.

Set-User-Id
-----------

If you really have to install sendmail set-user-ID root, first build
the sendmail package normally using

        sh ./Build

Then you can use

        sh ./Build install-set-user-id

to install the package in the old (pre-8.12) way.  Make sure that
no submit.cf file is installed.  See devtools/README about
confSETUSERID_INSTALL which you need to define.