Recipe 10.13 Identifying the sendmail Administrator
ProblemYou want to avoid having administrators login as root to manage sendmail files. SolutionSelect or create a user account, other than root , that will be used to manage sendmail. Change file and directory ownership in order to give the selected account ownership of and access to all of the files necessary to maintain sendmail, without providing access to unneeded files. This can be simplified by keeping the sendmail configuration files in a limited number of directories. For example, on the sample system, operational files are kept in /etc/mail and development files are kept in /usr/local/src/sendmail-8.12.9 . Add a confTRUSTED_USER define to the sendmail configuration to identify the sendmail administrator. Here is an example using mailman as the user account name : dnl The mail administration account is mailman define(`confTRUSTED_USER', `mailman') Build and install sendmail.cf , and then restart sendmail as shown in Recipe 1.8. DiscussionThe TrustedUser option identifies the user that owns sendmail's administrative files, such as the database files. TrustedUser defaults to root . Override the default value with the confTRUSTED_USER define. For example, the confTRUSTED_USER define in Recipe 10.13.2 sets TrustedUser to mailman . Once a TrustedUser is defined, the TrustedUser is given ownership of files that might be maintained by the sendmail administrator. On most systems, this means changing the ownership of the sendmail development directory, the /etc/mail directory, and the files inside these directories to the TrustedUser . [6]
The file permissions in the development directory are properly set by the sendmail source code tar file. The /etc/mail file permissions are more sensitive, but they should already be properly set by the vendor on any system running sendmail. If you're not sure about the permissions set for your /etc/mail directory, see Table 10-1. Table 10-1. Permissions for selected /etc/mail files
The permissions for the /etc/mail directory are set to 755. Database source file permissions are set to 640. [7] Database permissions are set to 640, as are permissions on the .cf files. Permission on the helpfile are set to 444. Execute permissions are not granted to anyone , on any file. sendmail files that fall outside of the /etc/mail directory ”on some systems this might be /etc/sendmail.cf and /etc/aliases ” should also be owned by the TrustedUser and assigned permissions similar to those used for files in the /etc/mail directory. If the m4 master configuration file contains the confCONTROL_SOCKET_NAME define, the socket file must be owned by the TrustedUser and set to mode 600. The directory containing the socket file should be owned by root or the TrustedUser and set to mode 700. The TrustedUser does not own the mail queue or the mail spool directories ”those are still owned by the root user.
The root user, which is the default value for TrustedUser , is at least as secure as any other user ID. Changing the TrustedUser does not improve file security. It does, however, make it possible to maintain sendmail databases without using root privileges. Recipe 10.11 covers the DefaultUser option. The DefaultUser executes commands, such as mailers, but does not own files. The TrustedUser owns files but does not execute commands from within sendmail. This division of labor improves security. See AlsoSee Recipe 10.12 for information on confTRUSTED_USERS , with an "S", which is a define that is sometimes confused with confTRUSTED_USER . The sendmail book covers confTRUSTED_USER in Section 10.8.2.3 and Section 24.9.112, recommended file permissions in Section 10.5.4, and the confCONTROL_SOCKET_NAME define in Section 24.9.23. |
