IT Baseline Protection Manual - The Information Warfare Site

Safeguard Catalogue - Communications Remarks
____________________________________________________________________ .........................................
the preceding point, the availability of these commands can be verified,
e.g. by entering the vrfy useralias command.
- The configuration file sendmail.cf should belong to root, and read and
write access should also be confined to root. The same goes for the higherlevel
directories since, otherwise, by simply renaming these directories, it
is possible to generate a new sendmail.cf file.
- Identification of executable programmes or of files as valid addresses for a
recipient or sender must be prevented by the configuration of sendmail.cf
or, by appropriate measures, be confined to certain safe programmes and
files.
- The F command (that is, for instance, FX/path [^#]) which serves to define
classes should be used in the configuration file (sendmail.cf) only to read
files which anyhow can be read system-wide, as, otherwise, relevant
security information from protected files might become generally
available. The programme format of the F command (e.g. FXFehler! Es
wurde kein Textmarkenname vergeben./tmp/prg) should not be used!
- For definition of the delivery agent (e.g. Mlocal), only absolute paths may
be indicated (e.g. P=/bin/mail). Also the S (suid) flag should be set only
when any security problems involved have been resolved.
- For any file to which sendmail could write, e.g. sendmail.st for statistics,
only root should have write access, and it should also only be listed in the
directories belonging to root. The same goes for files used by sendmail,
such as :include: in mailing lists
- Privileged users like bin or root should not have a .forward file. If the user
or group write-access rights for this file are set incorrectly, or if a user
manages to get into a privileged group, he can generate a shell with the
privileged user ID.
In the case of normal users, only the owner should have write access to the
.forward file, and this must be located in a directory belonging to the
owner.
In case asystem-wide write access to a home directory needs to be
available, e.g. uucp, creation of a deleterious .forward file can be prevented
in the following way: A directory with the name .forward, the rights 000
and the owner root and, under this directory, a file also having the rights
000 and the owner root must be created so that nobody else but root can
modify or delete these files. In this case, the home directory of uucp should
also belong to root and be provided with the sticky bit (t). A similar
approach is recommended also for other configuration files (e.g. .login,
.cshrc) in directories which can system-wide be written to.
- Any executable programme, including uudecode in particular, should be
removed from the alias file. Moreover, the alias file and the pertinent
database should belong to root, and only root should have write access to
them.
- It must be borne in mind that any received mail might be corrupt.
Corruption can occur either in the mail queue or through log-in on port 25.
The first situation can be avoided if the mail queue directory belongs to
____________________________________________________________________ .........................................
IT-Baseline Protection Manual: Oktober 2000