If you really do not want to have to blame Sendmail, use Postfix instead and turn off Sendmail's set-UID bit and run it set-GID to a dedicated group instead to prevent someone else from taking advantage of its next vulnerability to be discovered. Note that Postfix is standard on SuSE now.

It Is Better To Ask Forgiveness Than Give Permission

The fourth key to keeping your Linux system secure is to use the most restrictive file permissions that you can that still allows it to operate normally. Number one here is to ensure that almost no files (including most directories and device files) have world write permission. Do not trust your Distro to have done this -- most get it wrong. I do the following to check for world-writable files:

find / ! -fstype proc -perm -2 ! -type l -ls > find.log

Exceptions to the no world write access include the /tmp/., /var/tmp/., and /usr/tmp/. directories that have permissions of 1777 and tty devices. Do not even grant world read permission normally to files whose contents are confidential or group permissions unless it makes sense to do so.

It also is important to disable programs that have their set-UID or set-GID bits set if they are not needed. This is because if a hacker can get non-privileged access, say by cracking a user's password by brute force guessing, he may be able to become root by taking advantage of a vulnerability in a program that is set-UID to root. This can be done by invoking the following commands:

find / ! -fstype proc -perm -4000 ! -type l -ls > find_uid.log

find / ! -fstype proc -perm -2000 ! -type l -ls > find_gid.log


Then, disable those that are not needed. They probably will include /usr/bin/rcp, /usr/bin/rsh, /usr/bin/rlogin, and /usr/bin/sperl5.6.1. The problem with simply removing them or even just doing a chmod on them is that you may want to undo your work later, even if you absolutely never will need them. I discovered this the hard way with sperl, a version of perl designed to support set-UID perl scripts. I was trying to install a security patch on the regular perl program. Unfortunately, Red Hat's up2date program is not very smart and refused to install the new version of perl unless sperl also was present.

Fortunately, I could undo my work - just long enough to install the patch and to re-disable sperl. My technique is to create a directory called "off" in each directory that has a set-UID or set-GID program that I wish to disable. I create the "off" directory to be owned by root mode 700. Then, I just move the affected programs into their respective "off" directories. For example, one could do the following as root:

cd /usr/bin

mkdir off

chmod 700 off

mv rcp rsh rlogin sperl5.6.1 other stuff off/.

Forget about telnet and non-anonymous FTP too. Use ssh, scp, and sftp instead.

A Notable Exception

A notable exception is the list of programs that you will need but which should not be set-UID. The mount and umount programs constitute this list. They only need to be set-UID if you want to allow ordinary users to mount and unmount file systems. Not you? Good. Secure them by doing: