|
Chapter 22 Security |
|
|
|
Chapter 22 Security |
|
One technique that attackers use to gain root privilege is to first become a semiprivileged user like bin or sys . Such semiprivileged users often own the directories in which root -owned files live. By way of example, consider the following:
drwxr-sr-x 11 bin 2560 Sep 22 18:18 /etc -rw-r-r- 1 root 8199 Aug 25 07:54 /etc/sendmail.cf
Here, the /etc/sendmail.cf configuration file is correctly writable only by root . But the directory in which that file lives is owned by bin and writable by bin . Having write permission on that directory means that bin can rename and create files. An individual who gains bin permission on this machine can create a bogus sendmail.cf file by issuing only two simple commands:
%mv /etc/sendmail.cf /etc/...%mv /tmp/sendmail.cf /etc/sendmail.cf
The original
sendmail.cf
is renamed
...
(a name that is not likely to be randomly noticed by the real system administrator). The bogus
/tmp/sendmail.cf
then replaces the original:
drwxr-sr-x 11 bin 2560 Sep 22 18:18 /etc -rw-r-r- 1 bin 4032 Nov 16 00:32 /etc/sendmail.cf
UNIX pays less attention to semiprivileged users than it does root . The user root , for example, is mapped to nobody over NFS, whereas the user bin remains bin . Consequently, the following rules must be observed to prevent malicious access to root -owned files:
All directories in the path leading to a root -owned file must be owned by root and writable only by root . This is true for all files, not just sendmail files.
Files owned by root must be writable only by root . Group write permission, although at times desirable, should consistently be avoided.
Because sendmail is running as root when processing the configuration file, care should be taken to ensure the safety of system files as well. All system directories and files must live in directories whose path component parts are owned by and writable only by root . All system files (except possibly suid or sgid files) must be owned by root and be writable only by root . If any program "breaks" after securing permissions, complain to your vendor at once!
The sendmail program, of necessity, needs to trust its configuration file. To aid in the detection of risks, it checks the permissions of its configuration file when first reading that file. If the file is writable by group or world, sendmail logs the following message: [13]
[13] This is done only when not in rule-testing mode to prevent spurious warnings when you already know you are using a weak configuration file with
-C.
configfile : WARNING: dangerous write permissions
If sendmail is being started as a daemon or is being used to initialize the aliases database, it will print the same message to its standard error output.
The
sendmail
program doesn't always run as
root
. When delivering mail, it often changes its identity into that of a nonprivileged user. When delivering to a
:include:
mailing list, for example, it can change its identity to that of the owner of the list. This too can pose security risks if permissions are not appropriate. Consider the following
aliases
file entry:
newprogs: :include:/usr/local/lists/proglist
Here, notification of new programs are mailed to the alias
newprogs
. The list of recipients is taken from the following file:
-rw-rw-r- 2 bin prog 704 Sep 21 14:46 /usr/local/lists/proglist
Because this file is owned by bin , sendmail changes its identity to bin when delivering to the list of recipients. Unfortunately, the file is also writable by the group prog . Anyone in the group prog can add a recipient to that list, including one of the form
|/tmp/x.sh
This tells sendmail to deliver a copy of the message by running the program (a shell script) /tmp/x.sh . The sendmail program (which is still running as bin ) executes that program as bin . Further, suppose the program /tmp/x.sh contains the following:
#!/bin/sh cp /bin/sh /tmp/sh chmod u+s /tmp/sh cat - > /dev/null exit 0
This causes
bin
first to make a copy of the Bourne shell in
/tmp
(a copy that will be owned by
bin
), then to set the
suid
bit on that copy (the
u+s
):
-rwsr-xr-x 1 bin 64668 Sep 22 07:38 /tmp/sh
The script then throws away the incoming mail message and exits with a zero value to keep sendmail unsuspecting. Through this process, an ordinary user in the group prog has created an suid shell that allows anyone to become the semiprivileged user bin . From the preceding discussion (see Section 22.5, "Permissions" ) you can see the trouble that can cause!
Mailing lists (
:include:
) must live in a directory, all the components of which are writable only by root. The lists themselves must be writable only by the owner. If the owner is an ordinary user, group write permissions can be enabled, provided that the user is advised of the risks.
Mailing list (
:include:
) files may safely be owned by
root
. When
sendmail
processes a
root
-owned mailing list, it changes itself to run as the user and group specified by the
DefaultUser
option (see
Section 34.8.15
). That option defaults to
daemon
but should be set to
nobody
and
nogroup
. The
DefaultUser
option should
never
be set to
root
.
The
~/.forward
file can pose a security risk to individual users. There is a higher degree of risk if the user is
root
or one of the semiprivileged users (such as
bin
). Because the
~/.forward
file is like an individual mailing list (
:include:
) for the user, risk can be encountered if that file is writable by anyone but the user. Consider the following for example:
drwxr-xr-x 50 george guest 3072 Sep 27 09:19 /home/george/ -rw-rw-r- 1 george guest 62 Sep 17 09:49 /home/george/.forward
Here, the user
george
's
~/.forward
file is writable by the group
guest
. Anyone in group
guest
can edit
george
's
~/.forward
file, possibly placing something like this into it:
\george |"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"
Now all the attacker has to do is send
george
mail to create an
suid
george
shell. Then, by executing
/home/george/.x
, the attacker becomes
george
.
The semiprivileged users such as bin , and root in particular, should never have ~/.forward files. Instead, they should forward their mail by means of the aliases file directly.
User ~/.forward files must be writable only by the owning user. Similarly, user home directories must live in a directory that is owned and writable only by root , and must themselves be owned and writable only by the user.
Some users, such as the pseudo-user uucp , have home directories that must be world-writable for software to work properly. If that software is not needed (if a machine, for example, doesn't run UUCP software), that home directory should be removed. If the directory must exist and must be world-writable, you should create a protected ~/.forward file there before someone else does. The best protection is to create a nonempty directory called ~/.forward , owned by root , and set its permissions to 000:
#cd ~uucp#rm -f .forward#mkdir .forward#touch .forward/uucp#chown root .forward .forward/uucp#chmod 000 .forward .forward/uucp#chmod +t ~uucp#chown root ~uucp
Even though the
~uucp
directory is world-writable (so anyone can remove anything from it), no one but
root
can remove the
~/.forward
directory because it is not empty. The mode of 000 protects the file
.forward/uucp
from being removed. The mode of
+t
prevents users from renaming files or directories that they do not own. Finally,
root
is made to own the
~uucp
directory so that
uucp
will be unable to clear the
+t
bit. Even with this protection, mail for
uucp
should be routed to a real user with the
aliases
(5) file.
Note that all critical dot files in a world-writable home directory must be protected from creation by others. Each of
.forward
,
.rhosts
,
.login
,
.cshrc
,
.profile
, and
.logout
should be a nonempty,
root
-owned directory with mode 000. World-writable home directories must be owned by
root
instead of by the user, and they must have the
+t
(sticky bit) set.
When processing a user's
~/.forward
file,
sendmail
requires that the file be owned by the user or by
root
. If ownership is correct, it then examines the
~/.forward
file's permissions. If that file is world-writable,
sendmail
ignores (and logs) attempts to run programs and to write directly to files. If the
UnsafeGroupWrites
option (see
Section 34.8.73, UnsafeGroupWrites
) is true,
sendmail
also checks for group write permissions and, if it is found, similarly ignores attempts to run programs and to write to files.
Table 22.1 shows the recommended ownerships and permissions for all the files and directories in the sendmail system. The path components will vary depending on the vendor version of sendmail you are running. For example, where we show the /usr/lib/sendmail directory, your site may use /usr/etc/sendmail , or even /usr/lib/mail/sendmail .
| Path | Type | Owner | Mode | |
|---|---|---|---|---|
| / | Directory | root | 0755 |
drwxr-xr-x
|
| /usr | Directory | root | 0755 |
drwxr-xr-x
|
| /usr/lib [14] | Directory | root | 0755 |
drwxr-xr-x
|
| /usr/lib/sendmail | File | root | 06511 |
-r-s--s--x
[15] |
| /etc | Directory | root | 0755 |
drwxr-xr-x
|
| /etc/sendmail.cf | File | root | 0644 or 0640 | |
OS
/etc/sendmail.st
|
File | root | 0644 |
-rw-r--r--
|
OH
/etc/sendmail.hf
|
File | root | 0444 |
-r--r--r--
|
OA
/etc/aliases
|
File | root | 0644 |
-rw-r--r--
|
| /etc/aliases.pag | File | root | 0644 |
-rw-r--r--
|
| /etc/aliases.dir | File | root | 0644 |
-rw-r--r--
|
| /etc/aliases.db | File | root | 0644 |
-rw-r--r--
|
F
/path
|
Directory | root | 0755 |
drwxr-xr-x
|
F
/path/file
|
File | n/a | 0444 or 0644 | |
| /var | Directory | root | 0755 |
drwxr-xr-x
|
| /var/spool | Directory | root | 0755 |
drwxr-xr-x
|
OQ
/var/spool/mqueue
|
Directory | root | 0700[16] |
drwx---
|
:include:
/path
|
Directories | root | 0755 |
drwxr-xr-x
|
:include:
/path/list
|
File | n/a | 0644 |
-rw-r--r--
|
[14] The sendmail program sometimes lives in /usr/sbin or in some other directory. If so, adjust this path accordingly.
[15] The sendmail program may need to be sgid kmem for the load average to be checked on some systems.
[16] CERT (the Computing Emergency Response Team) recommends that the mqueue directory be mode 0700 to prevent potential security breaches.
|
|
|
|
| 22.4 The Configuration File |
|
22.6 The Aliases File |