Since Majordomo is responsible for managing E-mail lists, Majordomo relies heavily on a MTA such as Sendmail. There are other MTA's such as Smail and Qmail out there; however, Sendmail is the oldest and most common. This section introduces the reader to the areas of Sendmail that are useful or necessary to configure when using Majordomo.
The Sendmail aliases file (usually /etc/aliases) is used for making aliases for E-mail addresses. For example, once Majordomo is installed, usually an entry in the aliases file reads:
This entry means that all mail addressed to
[email protected] will actually be sent to
[email protected]. Notice it is unnecessary to append the
@host.com to
jarchie because both users are on the same host. If it were desired to redirect the message to a different user on a different host, one would have to add the
@host.com portion.
Another type of entry in the aliases file allows E-mail to be redirected to multiple addresses listed in a file:
testlist: :include:/usr/local/majordomo-1.94.5/lists/testlist
|
This entry states that any message sent to
[email protected] will be redirected to all the addresses listed in the file
/usr/local/majordomo-1.94.5/lists/testlist. The
testlist file might look something like this:
Majordomo is able to add or remove addresses from a list by taking advantage of this feature. When a
subscribe request is processed, the user's E-mail address is appended to the
testlist file; when an
unsubscribe request is processed, the user's E-mail address is removed from the
testlist file. One can also add or remove addresses manually simply by editing the file with a text editor such as
vi.
Since Majordomo needs to be able to process commands sent to it via E-mail, Sendmail must be able to execute the Majordomo program and pass the message to it. This is done by adding another type of entry to the aliases file:
majordomo: "|/usr/local/majordomo-1.94.5/wrapper majordomo"
|
The program
/usr/local/majordomo-1.94.5/wrapper is a wrapper (SUID
majordomo and SGID
majordomo or
daemon depending on the configuration) that runs the Majordomo program. The quotation marks around the second part of the alias entry are used to tell Sendmail that this part of the entry is all one statement; the quotation marks would be unnecessary if there were not a space between
wrapper and
majordomo. The
| is known as a "pipe"; it is used to tell Sendmail to send the E-mail to the wrapper via the standard input. (Since all the wrapper does here is to call
majordomo, the E-mail is actually being sent to Majordomo.) The wrapper accepts one parameter--the parameter of the program it is supposed to execute. (Any parameters after the first will be passed to the program the wrapper is executing.) For security reasons, the wrapper only executes programs located in the Majordomo directory,
/usr/local/majordomo-1.94.5/. This restriction prevents a programmer from using the wrapper to run programs that should not have Majordomo privileges. (For example,
wrapper /bin/vi would allow any user to edit any Majordomo configuration file.) When a message is sent to
[email protected], Sendmail starts up the wrapper which, in turn, starts up
majordomo, and Sendmail sends the message to the
majordomo script via the standard input. Majordomo then extracts the commands out of the message and responds appropriately.
Due to its arcane syntax, sendmail.cf is perhaps the most feared of all configuration files. In the installation of majordomo, it is not absolutely necessary to edit sendmail.cf; however, a couple of features are extremely useful. Unless major changes have to be made to sendmail.cf (which, thankfully, Majordomo does not require), editing the file is not that difficult. All that need be done is adding extra lines to the file.
Creating a separate file for the Majordomo aliases, such as /usr/local/majordomo-1.94.5/majordomo.aliases, is often a good idea. This can be done rather easily by adding a line to the end of the sendmail.cf file
OA/usr/local/majordomo-1.94.5/majordomo.aliases
|
To have a
/usr/local/majordomo-1.94.5/majordomo.aliases, Sendmail must be able to generate a database (
/usr/local/majordomo-1.94.5/majordomo.aliases.db). The easiest way to accomplish this is to go ahead and create an empty database for Sendmail to overwrite.
[root@kes majordomo-1.94.5]# touch majordomo.aliases.db
[root@kes majordomo-1.94.5]# chmod 644 majordomo.aliases.db
|
Another method to get around this issue is simply to create the
majordomo.aliases file in the
/etc/ directory, rather than the Majordomo home directory.
For certain setups, some security measures that Sendmail uses can prevent Majordomo from working properly. Obviously, these security features must be turned off.
Sendmail is programmed to make it difficult for people to make "perfect" forgeries of E-mail. For example, when a user sends a message via SMTP, the source IP address is typically logged, and when a user sends a message by giving it directly to Sendmail and specifying the sender using sendmail -f, Sendmail puts a warning message in the header specifying the user who really sent the message. However, some programs need to be able to send messages masquerading as other users, and having this extra security line appended to the header is annoying. Sendmail handles this problem by having trusted users. In order for Majordomo's resend script to work properly, majordomo must be a Sendmail trusted user since the program needs to resend mail from other users.
One way to make Majordomo a trusted user is by adding the line
to the
sendmail.cf file.
If Sendmail is using smrsh, then the only programs that can be executed are those under the /etc/smrsh/ directory. Perhaps the best solution to run the wrapper from the aliases file is to create a symbolic link from /etc/smrsh/wrapper to /usr/local/majordomo-1.94.5/wrapper.
[root@kes smrsh]# ln -s /usr/local/majordomo-1.94.5/wrapper wrapper
|
A second solution is to actually move the wrapper into the
/etc/smrsh/ directory.
[root@kes smrsh]# mv /usr/local/majordomo-1.94.5/wrapper ./
|
If security is not a major concern, the secure shell can be disabled. One fairly crude method is simply to delete
/usr/sbin/smrsh and copy or link
/bin/sh in its place.
[root@kes sbin]# rm -f smrsh
[root@kes sbin]# ln -s /bin/sh smrsh
|
A better (but more difficult) method is to edit
sendmail.cf. Change the reference from
/usr/sbin/smrsh
Mprog, P=/usr/sbin/smrsh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/,
T=X-Unix,
A=sh -c $u
|
to
/bin/sh
Mprog, P=/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/,
T=X-Unix,
A=sh -c $u
|
If you plan on having a non-root user add and manage mailing lists, you will need to make the majordomo.aliases file group writable. However, Sendmail does not allow this configuration for security reasons (see Section 2.4). To disable this security feature, add the line
O DontBlameSendmail=GroupWritableAliasFile
|
to the
sendmail.cf file. Also, the lists directory must be group writable in order to add a list, but Sendmail will not allow this setup for similar security reasons. To disable this security feature, adding the line
O DontBlameSendmail=IncludeFileInGroupWritableDirPath
|
to the
sendmail.cf configuration file is necessary.
For administrators who do not want to edit the sendmail.cf file directly, it is possible to use M4 to create the file; this section describes how to make the changes discussed in the previous section to the mc file instead of the cf file.
The purpose of the M4 configuration is to provide an easy way to create the sendmail.cf file. The idea is that the created mc file is easier to understand than the sendmail.cf file. By running the m4 preprocessor, a sendmail.cf file is generated:
[root@kes etc]# m4 /etc/sendmail.mc > /etc/sendmail.cf
|
Add the line
define(`ALIAS_FILE',`/etc/aliases,/usr/local/majordomo-1.94.5/majordomo.aliases')
|
to the
sendmail.mc file.
Add the line
define(`confTRUSTED_USERS',`majordomo')
|
to the
sendmail.mc file.
Delete the line that reads
in the
sendmail.mc file.
To disable the group write permission security check on the aliases file, add the line
define(`confDONT_BLAME_SENDMAIL',`GroupWritableAliasFile')
|
to the
sendmail.mc file.
To disable the path write permission security check for the include files, add the line
define(`confDONT_BLAME_SENDMAIL',`IncludeFileInGroupWritableDirPath')
|
To enable both of these options, use
define(`confDONT_BLAME_SENDMAIL',`GroupWritableAliasFile,IncludeFileInGroupWritableDirPath')
|
Adding the last statement is equivalent to writing
O DontBlameSendmail=GroupWritableAliasFile,IncludeFileInGroupWritableDirPath
|
in
sendmail.cf, and this entry is the same as writing the entries on separate lines:
O DontBlameSendmail=GroupWritableAliasFile
O DontBlameSendmail=IncludeFileInGroupWritableDirPath
|
Security is inversely proportional to convenience; the only secure machine is one that cannot be accessed by anyone. When some of Sendmail's security features are disabled, a machine will inevitably become less secure. However, it is important to understand the basic security risks in order to determine if the convenience out weighs possible breaches of security.
If a user has write permission to access an aliases file, she should be a trusted user. By putting an entry into the aliases file (such as the one used to execute wrapper) a user can execute any program with the privileges of Sendmail (daemon or, in older versions, root). This gaffe would allow people to remove or change the permissions of files that belong to daemon (using the rm or chmod commands in the aliases file). To some extent, this possibility is avoided by using smrsh; however, one must still be careful as to what files are in the /etc/smrsh/ directory.
Another important security issue is that the user who can access the aliases file can append or write to files that belong to daemon by using file redirection (a >> or > instead of a |). Even so, this breach too can be countered by adding a line to the sendmail.cf file limiting what files can be written to through the aliases file. Add the line
O SaveFileEnvironment=/path/to/safe/files
|
to the
sendmail.cf file or add
define(`confSAFE_FILE_ENV',`/path/to/safe/files')
|
to the
sendmail.mc file. However, this maneuver only leaves a thin layer of security between the user and
daemon. A much better idea would be to have the aliases file only writable by root and to create an SUID root program to add and remove the Majordomo related aliases.
In the case of include or .forward files, commands or redirections are run as the user who owns the file. Therefore, if a file is group writable, a member of the group can execute commands as the user who owns the file. In other words, any user in the majordomo group could execute commands as Majordomo. However, since the majordomo user is created without a shell, commands or redirections will not be processed in include files owned by majordomo.
If a user has group write permission to a directory, for example /etc/, the user could simply move any file and create a new one in its place. An attack might go something like this
[mallory@kes etc]$ mv aliases ...
[mallory@kes etc]$ vi aliases
|
The user can then make her own aliases! This attack, however, could be prevented by Sendmail's security checking for unsafe group writable paths. Such an attack also would work with include and .forward files having unsafe paths.
In the case of Majordomo, the user in the majordomo group already has access to the include files, so this does not really compromise security. However, an administrator should be careful to prevent these undesirable unsafe group writable directory paths from occurring in the future because Sendmail will not check for them.
Unfortunately, sophisticated spammers can expand mail lists using the EXPN SMTP command. For this reason, administrators should disable this feature when serving mailing lists. Add the line
to the
sendmail.cf file or
define(`confPRIVACY_FLAGS',`noexpn')
|
to the
sendmail.mc file.