|
10.8 Security FeaturesWe now turn our attention from security problems to security features. Many security features are discussed in the various README files supplied with the sendmail source distribution. Others are discussed in brief in a security tutorial by Greg Shapiro (http://www.sendmail.org/~gshapiro/). In this section we discuss the most common security features:
10.8.1 Trusted UsersUnder pre-V8 sendmail, trusted users are those who are allowed to use the -f command-line switch (-f) to override the sender address with one of their own. V8.1 sendmail eliminated this configuration command. V8.7 restored it, but as a class, and uses that class only to suppress warning headers. V8.11 and above allow only users in that class to rebuild the aliases database. Trusted users are necessary for certain kinds of mail to flow properly. By way of example, the rmail(8) program of the UUCP suite of programs runs set-user-id to uucp. If rmail were not to use the -f command-line switch, all mail from UUCP would wrongly appear to come from the uucp user. To circumvent this problem, rmail runs sendmail as: /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 list to be dispatched as though it were sent from the address list-request (the -f). This causes errors to be returned to the maintainer of the list (the list-request), but replies still go to the real sender. Unfortunately, this scheme fails when mail is posted to list from the local machine. Recall that only trusted users can change the identity of the sender with -f. This is why V8.1 sendmail eliminated the concept of the trusted user (anyone could use the -f switch). 10.8.1.1 Declare trusted users (ignored V8.1 through V8.6)Trusted users are defined by those lines in the sendmail.cf file that begin with the uppercase letter T. Only trusted users can use the sendmail program's -f command-line switch to specify who sent the message. Beginning with V8.7 sendmail, the class t can also be used. The T sendmail.cf command must begin a line. One or more space-delimited usernames then follow on that same line. There can be multiple T commands in a sendmail.cf file, each adding names to the list of trusted users. Prior to V8 there could be, at most, MAXTRUST trusted users, where MAXTRUST was defined in conf.h when you compiled sendmail. Beginning with V8.7, there is no limit: T uucp The two T commands show that there might optionally be whitespace between the T and the first name in any list of names. They indicate that uucp, root, and daemon are trusted and have been added to the list of trusted users in that order. The two class declarations show a similar declaration for use beginning with V8.7 sendmail (but note that V8.7 and above can still use the old syntax). Prior to V8 sendmail, if you listed more than MAXTRUST trusted users, sendmail printed and syslog(3)'ed a message such as this: sendmail: too many T lines, 32 max This message was not fatal. The sendmail program issued it for each excess T line (ignored those trusted users) and continued to run. V8 sendmail has implemented trusted users as a class, and there is no longer any limit imposed. Prior to V8 sendmail, if a user who was not trusted attempted to use the -f switch, that attempt was silently ignored (silently disallowed). Beginning with V8.7 sendmail, if a user who is not trusted attempts to use the -f switch, that attempt can produce an X-Authentication-Warning: header (X-Authentication-Warning:) if the PrivacyOptions option (PrivacyOptions) has authwarnings listed. Even though some users find them annoying, we recommend that you always enable X-Authentication-Warning: headers. They warn of suspicious behavior. If the behavior is legitimate, modify that behavior to eliminate the header instead of eliminating the more valuable warning headers. 10.8.2 Security OptionsThe sendmail program offers several options that can help you to improve the security at your site. Some we have discussed already. 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. 10.8.2.1 The DefaultUser optionThe DefaultUser option (DefaultUser) can be used to ensure that the default identity (when it is not running as root) is a safe one. CERT recommends that you create a pseudo-user whose uid and gid are used nowhere on your system, then define the DefaultUser option to be that pseudo-user. As an additional precaution, make sure that pseudo-user lacks a valid shell and has no valid home directory: mailnull:*:32765:32765:Sendmail Default User:/no/such/directory:/bin/false At the same time, set up a group entry for this user's group: mailnull:*:32765: This is necessary if you want to refer to this group symbolically at some later time. This is also recommended to avoid the risk of someone else reusing that group ID for another purpose in the future. 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.[23] For example, if nobody has the uid 65534, you could set up:
mailnull:*:65533:65533:Sendmail Default User:/no/such/directory:/bin/false 10.8.2.2 The RunAsUser option (V8.8 and above)The RunAsUser option (RunAsUser) is just like the DefaultUser option (DefaultUser) described earlier. But, instead of setting the identity to be used when sendmail is not running as root, this option sets the identity to replace root. Because a non-root program cannot assume the identity of other users, this option cannot be used in conjunction with the DefaultUser option. Instead, this option sets the only identity that sendmail will use. Although it is tricky to get sendmail to run as a non-root process in all circumstances, V8.12 offers a way to get part of sendmail to do this. The idea is that initial mail submission (by local users) can be sent safely with a non-root sendmail, whereas handling inbound mail and local delivery can require a root process. V8.12 handles this division by creating two separate sendmail processes, handling the two separate roles. See Section 2.6.2 for a complete explanation of this process. 10.8.2.3 The TrustedUser option (V8.10 and above)The TrustedUser option (TrustedUser) defines the user that can administer sendmail. If set, this user will own database map files (such as aliases), and will also own the control socket (ControlSocketName). Even though only root can start sendmail, this user can stop and restart the sendmail daemon. By setting this option, you can employ a user other than root to administer sendmail. But, if you have been administering sendmail as root, you cannot simply set this option and be done. Instead you need to shut down sendmail, make a few changes, then restart. The first change is needed to ensure that this trusted user can edit the source files for database files created by sendmail (the aliases database). The second change is needed to remove the control socket (if you use one) so that sendmail can create it with the proper ownerships. With these simple changes in place, you can add the following line to your mc configuration file, and build and install a new configuration file from it: define(`confTRUSTED_USER',`user')
Here, user is a user login name, or a user ID number. When you restart sendmail with this new trusted user in place, you can thereafter routinely employ that user to administer sendmail. 10.8.2.4 The ForwardPath optionThe ForwardPath option (ForwardPath) lists a series of directories that sendmail will search for user ~/.forward files. At most sites there are users who are savvy and able to correctly administer their own ~/.forward files, but there are others who are untrained or careless. You can allow experienced users to use the ~/.forward facility, while denying this ability to the others with the ForwardPath option: O ForwardPath=/usr/local/etc/forwards/$u.forward:$z/.forward Here, sendmail will first search the /usr/local/etc/forwards directory to find a file that begins with the user's login name (the $u, $u) followed by a .forward. If you set up such a file for the untrained user—say, bob: -rw-r--r-- 1 root system 0 Dec 13 2002 /usr/local/etc/forwards/bob.forward and if that file is empty, bob's mail will always be delivered locally, regardless of what bob puts in his ~/.forward file. For experienced users you can omit their files from the /usr/local/etc/forwards directory, thus enabling them to use their own ~/.forward files. 10.8.2.5 The LogLevel optionThe sendmail program normally logs a great deal of useful information via syslog (Section 14.3.1). 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. Because 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 LogLevel option (LogLevel): O LogLevel=12 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 (Section 1.7.6). 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: # kill -HUP `head -1 /etc/sendmail.pid` 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. 10.8.2.6 The PostmasterCopy optionThe PostmasterCopy option (PostmasterCopy) causes a copy of every bounced message to be delivered to a named user. Usually, that user is the person who handles email problems. But because clumsy intrusion attempts can result in bounced mail, there will be times when bounced mail should also be delivered to the security administrator. Consider the following: ----- Transcript of session follows ----- >>> RCPT To:<root@your.site.domain> <<< 550 cannot open /tmp/.../getshell: No such file or directory 550 5.7.1 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 PostmasterCopy option: O PostmasterCopy=postmaster,securitymaster
Here, securitymaster (probably an alias to a real user) was added. 10.8.2.7 The PrivacyOptions optionThe PrivacyOptions option (PrivacyOptions) is used to limit the amount of information offered to the outside world and to limit other kinds of access. The most restrictive setting for the PrivacyOptions option is probably best: define(`confPRIVACY_FLAGS', `goaway,restrictmailq,restrictqrun') This setting disables the EXPN and VRFY SMTP commands, requires other sites to identify themselves before sending mail, and also limits access to the mail queue directory. As a side effect, it also disables DSN parameters because goaway includes noreceipts. If that is a problem for you, you can manually set up everything that goaway does, but exclude noreceipts.[24] Note that the following line is split to fit the page:
define(`confPRIVACY_FLAGS', `needmailhelo,noexpn,novrfy,noverb,authwarnings, restrictmailq,restrictqrun') As a general rule, it is best to begin with tight security. This minimizes your risk from the beginning and allows you to cautiously ease restrictions at a comfortable rate. Beginning with loose restrictions can force you to tighten restrictions in a panic when it is least convenient to do so. 10.8.2.8 The SafeFileEnvironment optionBeginning with V8.7 sendmail, the SafeFileEnvironment option (SafeFileEnvironment) determines how delivery will be made to files. Ordinarily, sendmail will deliver to anything, provided that it has permission to do so (Section 12.2.2). It can, for example, deliver by appending to ordinary files or by writing to a device such as /dev/log. If the SafeFileEnvironment option is declared, sendmail will deliver only to ordinary files. This improves security by preventing anyone from scribbling over sensitive things, such as directories and devices. (Beginning with V8.8 sendmail, it is still OK to write to /dev/null even though this option is set.) The SafeFileEnvironment option can also be used to define a directory under which all files that will be appended to must exist. This might inconvenience some users but will generally improve the security of your site. We recommend: O SafeFileEnvironment=/path
This takes care of both security enhancements. Of course, you will need to create the directory specified in /path and populate it with the appropriate files. Note that, just before appending to a file, sendmail does a chroot(2) into /path. As a consequence an entry such as the following requires that the full path exist, such as /path/admin/mail: bob: \bob, /admin/mail/bob.archive But sendmail is also clever, and if an aliases path begins with the same path as the SafeFileEnvironment path, that latter path is removed before the write: bob: \bob, /path/admin/mail/bob.archive Here, because the SafeFileEnvironment option specifies /path, sendmail will perform the chroot(2) into /path, then will strip /path from the aliases file entry to form /admin/mail. 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 by defining /path as the root directory: O SafeFileEnvironment=/
10.8.2.9 The TempFileMode and QueueFileMode optionsThe TempFileMode option (TempFileMode) specifies the mode (file permissions) to give all temporary files and queue files. Beginning with V8.12, the QueueFileMode option (QueueFileMode) specifies the permissions given to queue files. In general, all files that are created by sendmail should be considered proprietary for safety's sake. We recommend a setting of: O TempFileMode=0600 With this narrow setting, the risk of accidental or malicious easing of permissions of your mail archive directories or queue becomes less of a risk. 10.8.3 The /etc/shells FileTo 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: |"/some/program" /save/to/a/file 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.[25] If that file does not exist, sendmail looks up the shell in its internal list, which looks (more or less) like this:[26]
/bin/bsh /bin/csh /bin/ksh /bin/pam /bin/posix/sh /bin/rksh /bin/rsh /bin/sh /bin/tcsh /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/tcsh 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 ftp@here.us.edu doesn't have a valid shell for mailing to programs User ftp@here.us.edu doesn't have a valid shell for mailing to files Note that unusual circumstances might require you to allow users with invalid shells to run programs 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: /SENDMAIL/ANY/SHELL/ 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:/bogus/shell 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. Be warned, however, that if a user can get into your machine as ftp, it can be possible for that user to run another shell, such as csh(1). Thus, in addition to listing a bogus shell, you might need to take further steps to prevent such access. |
legal in V8.1 through V8.6 but ignored
Troot daemon 
added|
|