11.6.1.1 World-writable user files and directories

Many inexperienced users (and even careless experienced users) often make themselves vulnerable to attack by improperly setting the permissions on files in their home directories.

The .login file is a particularly vulnerable file. For example, if a user has a .login file that is world-writable, an attacker can modify the file to do his bidding. Suppose a malicious attacker inserts this line at the end of a user's .login file:

/bin/rm -rf ~

Whenever a user logs in, the C shell executes all of the commands in the .login file. A user whose .login file contains this nasty line will find all of his files deleted when he logs in!

Suppose the attacker appends these lines to the user's .login file:

/bin/cp /bin/sh /usr/tmp/.$USER
/bin/chmod 4755 /usr/tmp/.$USER

When the user logs in, the system creates a SUID shell in the /usr/tmp directory that will allow the attacker to assume the identity of the user at some point in the future.

In addition to .login, many other files pose security risks when they are world writable. For example, if an attacker modifies a world-writable .rhosts file, she can take over the user's account via the network.

In general, the home directories and the files in the home directories should have the permissions set so that they are only writable by the owner. Many files in the home directory, such as .rhosts, should only be readable by the owner as well. This practice will hinder an intruder in searching for other avenues of attack.

11.6.1.2 Writable system files and directories

There is also a risk when system files and directories are world writable. An attacker can replace system programs (such as /bin/ls) with new programs that do the attacker's bidding. This practice is discussed in Chapter 8, Defending Your Accounts.

NOTE: If you have a server that exports filesystems containing system programs (such as the /bin and /usr/bin directories), you may wish to export those filesystems read-only. Exporting a filesystem read-only renders the client unable to modify the files in that directory. To export a filesystem read-only, you must specify the read-only option in the /etc/exports file on the server. For example, to export the /bin and /usr/bin filesystems read-only, specify the following in your /etc/dfs/dfstab file:

share -F nfs -o ro=client /bin
share -F nfs -o ro=client /usr/bin

On a Berkeley-based system, place these lines in your /etc/exports file:
/bin       -ro, access=client
/usr/bin   -ro, access=client

Group-writable files

Sometimes, making a file group writable is almost as risky as making it world writable. If everybody on your system is a member of the group user, then making a file group-writable by the group user is the same as making the file world-writable.

You can use the find command to search for files that are group writable by a particular group, and to print a list of these files. For example, to search for all files that are writable by the group user, you might specify a command in the following form:

# find / -perm -020 -group user \!   
\( -type l -o -type p -o -type s \) -ls

If you have NFS, be sure to use the longer version of the command:

# find / \( -local -o -prune \) -perm -020 -group user \!   
\( -type l -o -type p -o -type s \) -ls

Often, files are made group writable so several people can work on the same project, and this may be appropriate in your system. However, some files, such as .cshrc and .profile, should never be made group writable. In many cases, this rule can be generalized to the following:

Any file beginning with a period should not be world writable or group writable.

A more security-conscious site can further generalize this rule:

Files that begin with a period should not be readable or writable by anyone other than the file's owner (that is, they should be mode 600).

Use the following form of the find command to search for all files beginning with a period in the /u filesystem that are either group writable or world writable:

# find /u -perm -2 -o -perm -20 -name .\* -ls

NOTE: As noted earlier, if you're using NFS, be sure to add the -local or -xdev option to each of the find commands above and run them on each of your servers, or use the fstype/prune options.

11.6.1.3 World-readable backup devices

Your tape drive should not be world readable. Otherwise, it allows any user to read the contents of any tape that happens to be in the tape drive. This scenario can be a significant problem for sites which do backups overnight, and then leave the tape in the drive until morning. During the hours that the tape is awaiting removal, any user can read the contents of any file on the tape.