10.5 Permissions

One technique that attackers use to gain root privilege is to first become a semiprivileged user such as bin or sys. Such semiprivileged users often own the directories in which root-owned files live. By way of example, consider the following:

drwxr-sr-x 11 bin      2560 Sep 22 18:18 /etc/mail
-rw-r--r--  1 root     8199 Aug 25 07:54 /etc/mail/sendmail.cf

Here, the /etc/sendmail.cf configuration file is correctly writable only by root. But the directory in which that file lives is owned by bin and writable by bin. Having write permission on that directory means that bin can rename and create files. An individual who gains bin permission on this machine can create a bogus sendmail.cf file by issuing only two simple commands:

% mv /etc/mail/sendmail.cf /etc/mail/...
% mv /tmp/sendmail.cf /etc/mail/sendmail.cf

The original sendmail.cf is renamed ... (a name that is not likely to be randomly noticed by the real system administrator). The bogus /tmp/sendmail.cf then replaces the original:

drwxr-sr-x 11 bin      2560 Sep 22 18:18 /etc/mail
-rw-r--r--  1 bin      4032 Nov 16 00:32 /etc/mail/sendmail.cf

Unix pays less attention to semiprivileged users than it does root. The user root, for example, is mapped to nobody over NFS, whereas the user bin remains bin. Consequently, the following rules must be observed to prevent malicious access to root-owned files:

• All directories in the path leading to a root-owned file must be owned by root and writable only by root. This is true for all files, not just sendmail files.

• Files owned by root must be writable only by root. Group write permission, although at times desirable, should consistently be avoided.

• Because sendmail is running as root when processing the configuration file, care should be taken to ensure the safety of system files as well. All system directories and files must live in directories whose path component parts are owned by and writable only by root. All system files (except possibly set-user-id or set-group-id files) must be owned by root and be writable only by root. If any program "breaks" after securing permissions, complain to your vendor at once!

10.5.1 Dangerous Write Permissions

The sendmail program, of necessity, needs to trust its configuration file. To aid in the detection of risks, it checks the permissions of its configuration file when first reading that file. If the file is writable by group or world, sendmail logs the following message:^[14]

^[14] This is done only when not in rule-testing mode to prevent spurious warnings when you already know you are using a weak configuration file with -C.

configfile: WARNING: dangerous write permissions

If sendmail is being started as a daemon or is being used to initialize the aliases database, it will print the same message to its standard error output.

10.5.2 Permissions for :include:

The sendmail program doesn't always run as root. When delivering mail, it often changes its identity into that of a nonprivileged user. When delivering to a :include: mailing list, for example, it can change its identity to that of the owner of the list. This, too, can pose security risks if permissions are not appropriate.^[15] Consider the following aliases file entry:

^[15] We refer here to both file permissions and to permissions granted by the DontBlameSendmail option (Section 10.5.5). Beginning with V8.9, for example, the behavior we describe requires the DontBlameSendmail option to be set to GroupWritableIncludeFileSafe.

newprogs: :include:/usr/local/lists/proglist

Here, notification of new programs is mailed to the alias newprogs. The list of recipients is taken from the following file:

-rw-rw-r--  2 bin  prog   704 Sep 21 14:46 /usr/local/lists/proglist

Because this file is owned by bin, sendmail changes its identity to bin when delivering to the list of recipients. Unfortunately, the file is also writable by the group prog. Anyone in the group prog can add a recipient to that list, including one of the form:

|/tmp/x.sh

This tells sendmail to deliver a copy of the message by running the program (a shell script) /tmp/x.sh. The sendmail program (which is still running as bin) executes that program as bin. Further, suppose the program /tmp/x.sh contains the following:

#!/bin/sh
cp /bin/sh /tmp/sh
chmod u+s /tmp/sh
cat - > /dev/null
exit 0

This causes bin first to make a copy of the Bourne shell in /tmp (a copy that will be owned by bin), then to set the set-user-id bit on that copy (the u+s):

-rwsr-xr-x  1 bin    64668 Sep 22 07:38 /tmp/sh

The script then throws away the incoming mail message and exits with a zero value to keep sendmail unsuspecting. Through this process, an ordinary user in the group prog has created a set-user-id shell that allows anyone to become the semiprivileged user bin. From the preceding discussion (Section 10.5) you can see the trouble that can cause!

Mailing lists (:include:) must live in a directory, all the components of which are writable only by root. The lists themselves should be writable only by the owner.

Mailing list (:include:) files can safely be owned by root. When sendmail processes a root-owned mailing list, it changes itself to run as the user and group specified by the DefaultUser option (DefaultUser). That option defaults to daemon^[16] but should be set to the mailnull user and mailnull group. The DefaultUser option should never be set to root.

^[16] Actually, beginning with V8.10, it defaults to whichever of the following is found first to exist in the passwd file: mailnull, sendmail, or daemon. If none of those exists, the default becomes 1:1.

10.5.3 Permissions for ~/.forward Files

The ~/.forward file can pose a security risk to individual users. There is a higher degree of risk if the user is root or one of the semiprivileged users (such as bin). Because the ~/.forward file is like an individual mailing list (:include:) for the user, risk can be encountered if that file is writable by anyone but the user.^[17] Consider the following, for example:

^[17] Beginning with V8.9, the problem we describe is not possible with the default settings of the configuration file. However, if you enable the DontBlameSendmail option (Section 10.5.5) with a setting of GroupWritableForwardFileSafe, you override the default safety features and allow this dangerous behavior.

drwxr-xr-x 50 george guest        3072 Sep 27 09:19 /home/george/
-rw-rw-r--  1 george guest          62 Sep 17 09:49 /home/george/.forward

Here, the user george's ~/.forward file is writable by the group guest. Anyone in group guest can edit george's ~/.forward file, possibly placing something such as this into it:

\george
|"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"

Now all the attacker has to do is send george mail to create a set-user-id george shell. Then, by executing /home/george/.x, the attacker becomes george.

The semiprivileged users such as bin, and root in particular, should never have ~/.forward files. Instead, they should forward their mail by means of the aliases file directly.

User ~/.forward files must be writable only by the owning user. Similarly, user home directories must live in a directory that is owned and writable only by root, and must themselves be owned and writable only by the user.

Some users, such as the pseudo-user uucp, have home directories that must be world-writable for software to work properly. If that software is not needed (if a machine, for example, doesn't run UUCP software), that home directory should be removed. If the directory must exist and must be world-writable, to ensure that the ~/.forward file is never processed you can create an alias in the aliases database for uucp that points to root. For example:

uucp:   root

Thereafter, although the ~uucp directory is world-writable (so that anyone can remove anything from it), that file will be ignored by sendmail, even if someone places a ~/.forward file in it.

Note that all critical dot files in a world-writable home directory must be protected from creation by others. Each of .rhosts, .login, .cshrc, .profile, and .logout, for example, should be made a nonempty, root-owned directory with mode 000. World-writable home directories must be owned by root instead of by the user, and they must have the +t (sticky bit) set.

When processing a user's ~/.forward file, sendmail requires that the file be owned by the user or by root. If ownership is correct, it then examines the ~/.forward file's permissions. If that file is world- or group-writable, sendmail ignores (and logs) attempts to run programs and to write directly to files.

10.5.4 Recommended Permissions

Table 10-1 shows the recommended ownerships and permissions for all the files and directories in the sendmail system. The path components will vary depending on the vendor version of sendmail you are running. For example, where we show the /usr/sbin/sendmail directory, your site might use /usr/lib/sendmail, or even /usr/lib/mail/sendmail.

In Table 10-1 we show the owner as root, or as a T, which means the owner can be the user listed with the TrustedUser option (TrustedUser), or as an R, which means the owner must be the one specified by the RunAsUser option (RunAsUser) if that option was specified. Under the Owner column, we add a colon and show the group when the group is important.

^[18] The sendmail program sometimes lives in /usr/lib or in some other directory. If so, adjust this path accordingly.

^[19] As of V8.12, sendmail is no longer set-user-id root, but is instead set-group-id smmsp or the like, and sendmail is only root when it is run by root. The older versions of sendmail might need to be set-group-id kmem for the load average to be checked on some systems.

^[20] CERT (the Computing Emergency Response Team) and the sendmail document doc/op/op.me recommend that the queue directories be mode 0700 to prevent potential security breaches.

10.5.5 Don't Blame sendmail

In DontBlameSendmail of Chapter 24, we describe the DontBlameSendmail option, which can be used to allow looser permissions. We mention this option here because its misuse can lead to a weakening of security.

Consider a site where you use group permissions to allow system administrators to edit :include: files, rather than allowing them to do so by becoming root. Note that these mailing lists include archive files—that is, entries that append messages to archive files.

Unless you tell sendmail otherwise, it will refuse to run programs listed in such group-writable :include: files, and also refuse to append to any files listed in such :include: files (append to archive files). Every time mail is sent to such a mailing list, sendmail will log the following warning:

/path: group writable :include: file, marked unsafe

You can prevent this warning and allow running of disallowed programs and appending to disallowed files by declaring the DontBlameSendmail option in your mc configuration file:

define(`confDONT_BLAME_SENDMAIL', `GroupWritableIncludeFileSafe')

This declaration tells sendmail that you consider it safe to append to archive files from inside :include: files, even when the :include: file is group-writable. The result is that you have streamlined your department's operation, but you have done so at a price.

The sendmail program is paranoid about group-writable permissions because such permissions open the door to intrusion by insiders. Group permissions are managed via the passwd and group files, and :include: files can be silently edited with no record made about what was done to them. Contrast this approach to one that uses sudo(8) or a similar program, to manage access to root and other privileges. The sudo(8) program executes programs (such as an editor to edit a :include: file) with special permissions (such as root) and logs a record of each command executed.

It is vastly better to keep sendmail's file permissions narrow and to use other security tools to manage those files. We recommend you never use the DontBlameSendmail option to loosen permissions. If you think you need to do so, you should review your overall approach. Try to find a safe way to satisfy your needs, rather than loosening sendmail's security behavior.