Many inexperienced users (and even careless experienced users) 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 that 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 that 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 an 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 or .ssh/authorized_keys 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 permissions set so that they are writable only by the owner. Many files in the home directory, such as .rhosts, should be readable only by the owner as well. This practice will hinder an intruder in searching for other avenues of attack.

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 19.

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

Alternatively, you may wish to equip your server with two sets of executables: one that the server uses for itself, and one that is used for file-sharing clients (e.g., the server’s /usr partition would be for its own use, while /nfsusr is the version of /usr that is used by NFS clients).

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 for 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:

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

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

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 that 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.