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
majordomo-owner@host.com will actually be sent
to
jarchie@host.com. 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
testlist@host.com 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:
johnarchie@emeraldis.com
srobirds@yahoo.com
acreswell@geocities.com
|
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
majordomo@host.com, 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.
Learn about Linux
Download Linux
Get Linux help
