This appendix discusses various issues relating to program delivery:
- Security Issues (Important!)
- How to set up program delivery
Program delivery is currently only available on UNIX platforms.
|
This appendix discusses various issues relating to program delivery:
Program delivery is currently only available on UNIX platforms. |
DELIVERING MAIL TO A PROGRAM(PROGRAM DELIVERY) |
This appendix explains how to set up post.office to deliver incoming messages to external programs.
Program delivery is currently only available on the UNIX platform.
Whether you answer dozens of requests for information every day, or simply need to separate your personal mail from your company in-box, automating the task with a program delivery will save you time and effort.
Each account in post.office can be configured to do a variety of things with messages that are received. Usually this involves putting the message in a mailbox, forwarding it somewhere else, or generating an automatic response. In some cases, it is desirable to do something else with incoming messages that is not possible with the built-in features. To accommodate the needs of advanced users that want tighter control over the handling of their mail, or to create autonomous services such as a file server, post.office offers the ability to deliver mail to external programs that can carry out these additional tasks.
By setting up a program delivery for an account, a custom program will be run whenever mail arrives for the account. The program is started by post.office as if it were logged into the host as the recipient of the mail, and the mail is handed over to the program. The program then does whatever it was designed to do to make life easier or more rewarding.
The following examples illustrate two situations where program deliveries are very helpful.
Anybody who receives a lot of E-mail knows the frustrations of wading through dozens of messages in their electronic mailbox, some personal, some work-related, and others from various mailing lists. If this is happening to you, there is a solution called a mail filter you should check out: messages are delivered to a filtering program as they arrive. The mail filter scans each message to determine which of several mailboxes it should put it in, and then delivers it there without the need for you to think about it.
An automatic filter can usually sort messages based on who the sender is or the subject of the message. The result is you don't have to waste your time organizing your messages; it's done for you automatically by the mail filter, leaving you free to peruse your messages one mailbox at a time.
Some sites have a lot of information that they wish to make publicly available. The most common way to share files on the Internet is to make them available via the File Transfer Protocol (FTP) or via the World Wide Web (WWW).
However there are lots of people who only have E-mail access to the net and can not benefit from such services. You can make files available to these folks by setting up a file server which can send documents in response to received E-mail requests. A request sent to your typical E-mail file server is a message that consists of one or more commands such as:
SEND /documents/internet/rfc/rfc0822.txt
The file server reads the commands it finds in the message and performs the appropriate actions, resulting in the requested files being delivered to the sender.
Security is (or should be) one of your fundamental concerns. This section covers the things you need to know to keep your mail server secure while allowing post.office to deliver mail to external programs.
The following terms are used throughout this appendix, so it is important that their definitions are fully understood.
A setuid-root program is one that acquires root permissions when it is run. Such programs need more permissions than those of the user that executes them to perform certain tasks. Setuid programs can be identified by an s as the user-execute permission in the output of ls -l as shown here:
-r-s--x--- 1 root mta 70064 Feb 17 10:32 Program-Deliver
A Controlling User is the UNIX user for whom a command is executed. This is the user specified in the UNIX-LoginName field of an account (see G.4 below). Before running a command, the program delivery module of post.office relinquishes its root permission and acquires the permissions of the controlling user (using the setuid(2) system call).
Many programs (especially shells such as /bin/sh, etc.) use information from environment variables to modify their behavior. To avoid the possibility of security problems, the only environment variables passed to an external program are TZ (time zone information), AGENT=post.office (for compatibility with sendmail), and sometimes PATH (see Operating Modes below).
When running post.office in an untrusted environment (see Operating Modes below), you can designate a collection of programs as trusted. Such programs are believed to behave nicely even if run by someone with malicious intent. Trusted programs typically consist of mail filters, distribution list software, automatic responders, and the like.
The program delivery module looks for trusted programs in a special directory known as the trusted program directory. Any executable file (or a hard or soft link to an executable) found in this directory is considered to be a trusted program. When the program delivery module runs a trusted program, it ignores the path specified in the user's account, and executes the one found in this directory. This allows the System Administrator to specify the exact executable files which will be run by the program delivery feature.
For example, if a user wants to set up a program delivery that notifies her whenever new mail arrives, she can specify it in her account as
/usr/local/bin/new_mail
/home/user3/bin/new_mail
or simply
new_mail
and the trusted version of the new_mail program found in the trusted program directory will be executed. The details of how to set up the trusted program directory are found later in this appendix.
Before running a program as a controlling user, the login shell of the user is checked against the list of valid shells found in /etc/shells. The /etc/shells file is simply a list of shells, one per line, that could be used to log into the system. If this file is missing or empty, the user's shell is checked against the following default list:
/bin/sh /usr/bin/sh
/bin/csh /usr/bin/csh
/bin/ksh /usr/bin/ksh
The thinking behind this check is that post.office shouldn't run commands for users that aren't normally allowed to log in and type the commands themselves.
To bypass this check you can insert an entry into /etc/shells containing the character sequence, MAIL/ANY/SHELL. Bypassing the check is not generally a good idea, especially if you have not set up a list of trusted programs.
The program delivery module in post.office can operate in one of two modes, depending on the level of security desired. The module determines which operating mode to use by checking for programs in the trusted program directory.
When the program delivery module is set up to run in untrusted mode, it can be as secure as you need it to be. Since the trusted programs are the only programs on the system that it will run, regardless of how accounts are set up, the security vulnerability of a system running post.office is limited to this small collection of programs.
It is critical that the behavior of each trusted program is well understood and known to be safe. In particular, programs that interpret their input as a sequence of commands (such as shells like sh and csh or scripting languages like perl and tclsh) should not be set up as trusted programs. However, some scripts that run under these command interpreters may be considered safe after careful inspection.
The following algorithm is used to deliver mail to a user with a valid shell when post.office is set up in untrusted mode:
Operating the program deliver module in trusted mode requires a lot of trust (perhaps too much) on the part of the system administrator.
The postmaster(s) need to be trusted not to set up accounts with improper system permissions since they can assign an arbitrary UNIX login to any account. Such an account can then be used to run commands as the assigned user, provided the user has a valid shell.
More importantly, the networks to which you are connected must be trusted. This is certainly not the case if you are connected to the global Internet, where so many tormented souls regularly attempt to break into your system that the untrusted mode should be used. If one of these system crackers were to compromise a post.office system, they might be able to set up accounts to provide them with privileged information, or to damage mail files. Of course they will never gain root privileges since no external program is ever run as root.
When opting for the trusted mode of operation, the system administrator can (and should) take precautions that minimize the risks. First of all, choose the postmaster carefully. If nobody is qualified and responsible, the best choice is to do it yourself or set up post.office to run in the untrusted mode. Secondly, set up special accounts such as bin, sys, adm, and so forth with shells that are not valid for delivering mail to programs. (Note: leaving the shell field blank does not accomplish this since a default of /bin/sh is assumed.) In the trusted mode of operation, it is especially important not to override the checking of valid shells in /etc/shells.
The following algorithm is used by post.office when delivering mail via the program delivery facility to a user with a valid shell:
The following instructions explain the steps that must be performed by a system administrator to enable program deliveries. It is important that the system administrator understands all of the implications of installing any setuid-root program on the system. Due to the security issues involved, the program delivery module is disabled by default and must be activated explicitly.
The commands shown in the examples assume that the executable programs have been installed in /opt/post.office. In the executable directory are several sub-directories, including local/ and trusted/, which are where the program delivery module and the trusted program directory, respectively, are located. If you do not have root privileges on the machine running post.office, you will have to find a system administrator to do these steps for you.
The program delivery module can be activated by performing two simple steps as root. The resulting mode of operation is the trusted mode, so further configuration is required to set up the untrusted mode (which is highly recommended for most situations) with a list of trusted programs (see below).
Whenever the program delivery module finds a file in the trusted program directory named NO-PROGRAM-DELIVERIES, it refuses to deliver mail to any program. If an account is configured to deliver mail to a program, post.office generates a verbose error message to the postmaster.
You must remove this file for program deliveries to work, and can create a new one at any time to disable the feature.
cd /opt/post.office/trusted rm NO-PROGRAM-DELIVERIES
(Note: the file name must be typed exactly as shown in all capital letters with dashes as shown in order to disable the program delivery feature).
In order to run programs as a controlling user, the program delivery module needs to be setuid-root. If the setuid-root permission bit is not set, messages destined for users' programs are deferred until either the setuid bit is enabled, or the maximum queue time expires and the message is returned to the sender.
cd /opt/post.office/local chmod u+s Program-Deliver
If you want to set up post.office to run in the more secure untrusted mode, you must set up some trusted programs. To do this, simply copy each program to the trusted program directory, or create a link in the directory to the program. This short example shows one way to set up a program called mail-filter as a trusted program:
cd /opt/post.office/trusted ln -s /usr/bin/mail-filter mail-filter
Note: It is important to remember that programs that interpret their input as a sequence of commands to execute (such as sh, tclsh, or perl) should not be set up as Trusted Programs. However, some scripts that run under such programs may be considered safe after careful inspection.
If you want to allow users with login shells other than sh, csh, or ksh to use the program delivery feature, you need to set up /etc/shells. Simply list all of the allowed shells, one per line, complete with their full pathnames. Note that if you are creating the /etc/shells file for the first time, you need to include entries for any of the six default shells that you wish to allow. Here's an example of a possible /etc/shells file:
% cat /etc/shells /bin/csh /bin/ksh /bin/tcsh /usr/bin/csh /usr/bin/ksh /usr/bin/tcsh %
As discussed previously, it is possible (though generally not advisable) to override the valid shell check by putting an entry in /etc/shells that contains the character sequence MAIL/ANY/SHELL. This may be used to allow any user to use the program delivery feature of post.office, but to restrict user access to FTP (which also does a valid shell check). An example /etc/shells file for this purpose might look like this:
% cat /etc/shells /bin/ksh /usr/bin/ksh /MAIL/ANY/SHELL/ %
You can disable the program delivery module simply by replacing the NO-PROGRAM-DELIVERIES file (Must be all capital letters with the dashes as shown).
So long as this file remains in the trusted program delivery, post.office will not deliver any mail to programs. To do this:
cd /opt/post.office/trusted touch NO-PROGRAM-DELIVERIES
(Note: the file name must be typed exactly as shown in all capital letters with dashes as shown in order to disable the program delivery feature).
The Postmaster sets up program deliveries by using the account form. In order to do so, you need a UNIX login which has a valid shell (see G.2.1 for definition). One or more programs should be listed in the trusted program directory (see G.3.2).
Notes: The program delivery facility is disabled by default, so you must turn it on before setting up any program deliveries (see G.3). Also, be sure to read section G.2, which discusses the security aspects of program deliveries.
This section assumes you have set up an account following the instructions that are on the account form or in chapter 5 of the manual. In order to implement program delivery, you should select program delivery as a delivery option (as per "Delivery:" field below) and indicate your command line argument in the "Program-Deliveries:" field. A valid UNIX login name should also be specified.
Figure G.4a, below, is a stripped down version of the account form illustrating how mail which is sent to mike@software.com is delivered to a program called "mail-filter":
User's-Real-Name: [Mike's Mailbox]
Internet-Addresses: [mike@software.com]
[]
[]
UNIX-Delivery: [No]
UNIX-LoginName: [mike]
Program-Delivery: [Yes]
Programs-To-Run: [/usr/bin/mail-filter -xyz -pdq mike]
[]
|
Figure G.4a: The figure above illustrates the key account form fields which relate to program delivery.
The command line argument in the "Program-Deliveries:" field should call out a program that is listed in the trusted program directory, unless the module is configured in trusted mode (which, as you may have noticed, we advise you not to do. See section G.2 for reason why). In the untrusted mode , you cannot use characters in the command that have special meaning to a shell.
The "UNIX-LoginName:" must be a valid UNIX login name.
Users set up program delivery using the information form.
This section assumes you are making a transition from having your mail delivered to your UNIX maildrop file to having it delivered to a program. In order to implement program delivery, you should select program delivery as a delivery option (as per "Current-Delivery-Items:" field below) and indicate your command line argument in the "Programs-To-Run:" field.
Figure G.5a, below, is a stripped down version of the information form illustrating how mail which is sent to mike@software.com is delivered to a program called "mail-filter":
UNIX-Delivery: [No]
UNIX-LoginName: [mike]
Program-Delivery: [Yes]
Programs-To-Run: [/usr/bin/sort-mail -args]
[]
|
Figure G.4a: The figure above illustrates the key information form fields which relate to program delivery.
The command line argument in the "Programs-To-Run:" field should call out a program that you would like to run.
There are certain controls on the use of program delivery which may interfere with the delivery you would like to set up. Thus, if you have any difficulty setting things up, contact the postmaster for your mail system to discuss your options regarding implementing program delivery.