Recipe 10.6 Controlling Delivery to Programs

Problem

Special configuration is needed to control which programs are started by the prog mailer.

Solution

Check the smrsh manpage for the location of the smrsh execution directory, which is usually either /etc/smrsh or /usr/adm/sm.bin . (The Discussion section shows how the smrsh program can be checked for the execution directory path .) If the smrsh program directory does not already exist, create the appropriate directory, making sure that it is owned by root and only writable by root . Here is an example:

 #  mkdir /usr/adm/sm.bin  #  chmod 751 /usr/adm/sm.bin

To make a program accessible via the prog mailer, create a symbolic link for the program in the smrsh execution directory. Here is an example of creating links to the vacation and slocal programs:

 #  cd /usr/adm/sm.bin  #  ln -s /usr/local/bin/vacation  #  ln -s /usr/lib/nmh/slocal

Add the smrsh feature to the sendmail configuration to use smrsh , the Sendmail Restricted Shell, as the binary for the prog mailer. Here is an example of the required FEATURE macro:

 dnl Use smrsh as the prog mailer FEATURE(`smrsh')

Build the sendmail.cf configuration file, copy it to /etc/mail/sendmail.cf , and restart sendmail, as described in Recipe 1.8.

Discussion

sendmail uses the prog mailer to deliver mail to a recipient address that begins with the pipe character. The P parameter of the prog mailer definition defines the path to the prog mailer program and the A parameter defines the command used to run the mailer. With the default sendmail configuration, the P parameter is P=/bin/sh and the A parameter is A=sh -c $u . $u is a sendmail macro that contains the email address of the user to which the mail is being delivered. For example, given the following .forward file:

 "/usr/lib/nmh/slocal -user reba"

the command executed for the prog mailer would be:

 /bin/sh -c "/usr/lib/nmh/slocal -user reba"

When the -c option is used with /bin/sh , shell commands are read from the string that follows -c . In this case, sendmail causes the shell to execute a program named slocal . sendmail attaches its output to the standard input of the shell and prints out the mail message, which, in the example, sends the mail message to the slocal program. sendmail also attaches the standard output and standard error of the shell to its input.

The shell will execute any command passed to it. The potential security risks of executing any command that follows the pipe character in a recipient address are obvious. Using the Sendmail Restricted Shell ( smrsh ) for the prog mailer instead of /bin/sh limits the commands that can be executed, thus enhancing security. smrsh enforces the following restrictions:

Only a few built-in shell commands ” exec , exit , and echo ”work; most do not.
Standard I/O redirection is not allowed.
Most of the special characters used by the shell ” carriage return, newline, <, >, ;, $, (, and ) ”are not allowed.
Most importantly, only those programs that you choose to make available to smrsh through its special program directory are available to the user. On a system running smrsh , mail addressed to programs not listed in the smrsh execution directory is rejected with the error "unavailable for sendmail programs."

The default path for the smrsh program directory is /usr/adm/sm.bin . Vendors often change the path. For example, the Red Hat sendmail RPM distribution defines the path as /etc/smrsh . To find out where your version of sendmail puts the smrsh program directory, check the manpage or look inside the smrsh program, using the following commands:

 #  grep '^Mprog' /etc/mail/sendmail.cf  Mprog,          P=/usr/sbin/smrsh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL,                 R=EnvToL/HdrToL, D=$z:/,  #  strings /usr/bin/smrsh  grep '^/'  /lib/ld-linux.so.2 /usr/adm/sm.bin /bin:/usr/bin:/usr/ucb /bin/sh

The first grep command prints out the first line of the prog mailer definition from the sendmail.cf file. The P parameter of the prog mailer definition tells us where sendmail expects to find the smrsh program. We use the value from the P parameter to point the strings command to the correct program. The strings command displays all of the literal strings found in the smrsh executable. We pass its output through grep to select only those strings that are pathnames. Because we know that the default path for the smrsh program directory is /usr/adm/sm.bin , it is easy to pick the program directory path out of this list.

To force smrsh to use some other directory as its program directory, recompile smrsh . The # define CMDDIR line in the smrsh.c source file points to the program directory. Compile smrsh with the -DSMRSH_CMDDIR compile option to specify a different directory path. This can be done by adding a command, such as the following, to the devtools/Site/site.config.m4 file:

 APPENDDEF(`conf_smrsh_ENVDEF', `-DSMRSH_CMDDIR=\"/etc/smrsh/\"')

Most administrators decide to create the program directory where smrsh expects to find it instead of recompiling smrsh to change the default path. When working with the sendmail tarball, creating your own /usr/adm/sm.bin directory is both easier and better than recompiling smrsh with compile options or modified source code; this is true for three reasons. First, most system administrators find the mkdir command easier to work with than the cc command or C source code. Second, this is the standard directory where most Unix administrators expect to find the smrsh programs. Third, the smrsh manpage that comes with the sendmail tarball tells readers that the programs are located in the /usr/adm/sm.bin directory. (If you change the directory, you should also change the manpage.) When using the sendmail distribution provided by a vendor, use the vendor's default directory. When using the sendmail tarball, use /usr/adm/sm.bin .

Populate the directory with the programs that are trusted to be accessible through the prog mailer. Programs are added to the smrsh program directory in two ways:

The program is moved to the directory.
A symbolic link is placed in the directory pointing to the program.

Recipe 10.6.2 uses symbolic links. This is the most popular way to add programs to the smrsh program directory. It is slightly less secure than actually moving programs to the directory because both the smrsh program directory and the other directories in which the programs actually reside must be secured against unauthorized changes. The more things there are to secure, the more likely a security mistake will be made. However, the risk is small, so most administrators prefer using symbolic links.

Take care when adding programs to the smrsh execution directory. Poorly written programs are popular targets for attackers . Additionally, do not add programs that can be used to launch other programs. Shells, such as /bin/sh , and programs, such as procmail , which can be directed by the user to start other programs, defeat the purpose of smrsh and thus do not belong in the smrsh execution directory. ^[3] Every program is a potential hole for an intruder to exploit. Choose them carefully .

^[3] Using procmail as the local mailer also defeats the purpose of smrsh .

In Recipe 10.6.2 two symbolic links are added to the smrsh program directory. On our sample system, these links allow access to:

The vacation program ”a program that automatically responds to mail when the user is out of the office for an extended period.
The slocal program ”a mail filtering program.

Users can then create .forward files that use these programs. For example, Kathy could define the following .forward file when she goes on vacation:

 \kathy, "/usr/local/bin/vacation kathy"

smrsh strips the initial pathname off of the program to which mail is being forwarded. Thus, when /usr/local/bin/vacation is the program name in the recipient address, smrsh strips the program name down to vacation and looks for a file of that name in the smrsh program directory.

Recipe 10.6 Controlling Delivery to Programs

Problem

Solution

Discussion

See Also