We now turn our attention from security problems to security features:
trusted users are those who are allowed to use the
Trusted users are necessary for certain kinds of mail to flow properly.
By way of example, the
(8) program of the UUCP suite of
were not to use the
/usr/lib/sendmail -f reallyfrom
This tells sendmail to show, in both the header and envelope, the message as being from reallyfrom , rather than from uucp .
The concept of a trusted user is intended to prevent ordinary users from changing the sender address and thereby forging mail. Although that intention is laudable and good for UUCP, it can cause problems with mailing lists. Consider the following:
list: "|/usr/lib/sendmail -oi -flist-request -odi list-real" list-real: :include:/export/share/mail-lists/list.list
The intention here is for all mail sent to the mailing list named
Unfortunately, this scheme fails when mail is posted to
Trusted users are defined by those lines in the
file that begin with the uppercase letter
T uucp legal in V8.1 through V8.6 but ignored Troot daemon legal in V8.1 through V8.6 but ignored Ct uucp V8.7 and above Ctroot daemon V8.7 and above
Prior to V8
, if you listed more than
sendmail: too many T lines, 32 max
This message was not fatal. The
it for each excess
Prior to V8
, if a user who was not trusted attempted to use the
One line of attack against all users, including root , is to modify a user's ~/.forward file (see Section 22.5.3, "Permissions for ~/.forward Files" ). Unless you take steps to prevent it, sendmail will run any program that it finds in a user's ~/.forward file:
\user |"/usr/ucb/vacation user" ok |"/tmp/x.sh" An attack! |"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x" An attack!
As an aid in preventing such attacks, V8
The smrsh program is supplied in source form with the sendmail distribution in the smrsh directory. The README file in that directory describes how to compile and install smrsh .
program replaces the
program in the
Thereafter, whenever smrsh is called to run a program, smrsh strips the leading path from the program name and looks for that program in its special /usr/adm/sm.bin directory. If the program is not found in that directory, the message bounces. Thus in our first attack example above, with smrsh installed and with x.sh not in the /usr/adm/sm.bin directory, the ~/.forward line
would cause the email message to bounce with this error:
smrsh: /usr/adm/sm.bin/x.sh: not found
|"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"
In this instance, smrsh would reject the command line (and thus bounce the message) because it contained a semicolon character:
smrsh: cannot use ; in command
The sendmail program offers several options that can help you to improve the security at your site. Some we have discussed above. We touch on a few more in this section, and provide a recommended setting where appropriate. For a full description of each, see the sections referenced.
nullmail:*:32765:32765:Sendmail Default User:/no/such/directory:/bin/false
At the same time, set up a group entry for this user's group:
This is necessary if you want to refer to this group symbolically at some later time.
Avoid using the name nobody , because root is mapped to nobody over NFS. If root were to create a file over NFS that it thought was safe because root owned it and because it was readable only by root , that root user would be surprised to find that file owned by nobody . Consequently, we recommend that in an NFS environment you set the default user to one less than nobody . For example, if nobody has the uid 65534, you could set up
nullmail:*:65533:65533:Sendmail Default User:/no/such/directory:/bin/false
will first search the
to find a file that begins with the user's login name (the
-rw-r-r- 1 root system 0 Dec 13 1996 /usr/local/etc/forwards/bob.forward
and if that file is empty, bob 's mail will always be delivered locally, no matter what bob puts in his ~/.forward file. For experienced users you can omit their files from the /usr/local/etc/forwards directory, thus enabling their use of their / .forward files.
program normally logs
a great deal of useful information
Section 26.1.1, "syslog(3)"
There will be times, however, when
the normal amount of information is insufficient. Consider, for example,
that some outsider is using your site to forge mail. Since this
is done over an SMTP connection, it would be handy to have
both sides of all SMTP conversations logged.
You can do this with the
O LogLevel=12 V8.8 and above to log SMTP
Beginning with V8.8 sendmail , a level of 12 causes both sides of every SMTP conversation to be logged. That logging looks very similar to the logging produced by verbose mode (see Section 4.2, "Verbose (-v)" ).
Note that after changing the log level in your configuration file you will need to restart the daemon. With V8.7 and above sendmail you restart the daemon like this:
Be aware that a log level of 12 produces a huge amount of output. Be prepared to prune your log files more often than usual.
--- Transcript of session follows --- ... while talking to your.site.domain.: >>> RCPT To:<email@example.com> <<< 550 cannot open /tmp/.../getshell: No such file or directory 550 cannot open /tmp/.../getshell: No such file or directory
This bounced mail message indicates that someone tried to become root by breaking through your aliases database.
Users are added to the list of those who get copies of bounced
messages with the
As a general rule it is best to begin with tight security. This minimizes your risk at the start and allows you to cautiously ease restrictions at a comfortable rate. Beginning with loose restrictions may force you to tighten restrictions in a panic when it is least convenient to do so.
Beginning with V8.7
This takes care of both security enhancements. Of course, you will need to create
the directory specified in
If all you want to do is prevent writing to directories and devices, and if you
do not want to place all files in a special path, you can accomplish this
To prevent certain users from running programs or writing to files by way of the aliases or ~/.forward files, V8 sendmail introduced the concept of a "valid shell." Just before allowing delivery via an alias such as these:
the user's password entry is looked up. If the shell entry from that password entry is a valid one, delivery is allowed. A shell is valid if it is listed in the /etc/shells file. If that file does not exist, sendmail looks up the shell in its internal list that looks (more or less) like this: 
/bin/bsh /bin/csh /bin/ksh /bin/pam /bin/posix/sh /bin/rksh /bin/rsh /bin/sh /bin/tsh /usr/bin/bsh /usr/bin/csh /usr/bin/keysh /usr/bin/ksh /usr/bin/pam /usr/bin/posix/sh /usr/bin/rksh /usr/bin/rsh /usr/bin/sh /usr/bin/tsh
With this technique it is possible to prevent certain users from having sendmail running programs or delivering to files on their behalf. To illustrate, consider the need to prevent the ftp pseudo-user from misusing sendmail :
ftp:*:1092:255:File Transfer Protocol Program:/u/ftp:/no/shell
Here, any attempt by ftp to send mail through a program or into a file will fail because the shell /no/shell is not a valid shell. Such mail will bounce with one of these two errors:
User firstname.lastname@example.org doesn't have a valid shell for mailing to programs User email@example.com doesn't have a valid shell for mailing to files
Note that unusual circumstances may require you to allow users with invalid shells to run program or deliver to files. To enable this for all such users (as on a mail server with restricted logins), place the following line directly in the /etc/shells file:
To enable this for selected users, just replace their shell with a bogus one that is listed in /etc/shells:
ftp:*:1092:255:File Transfer Protocol Program:/u/ftp:
We recommend that all pseudo-users (such as bin and ftp ) be given invalid shells in the password file and that /SENDMAIL/ANY/SHELL/ never be used.