No matter what the threat is called, how it enters your system, or what the motives of the person(s) who wrote it may be, the potential for damage is your main concern. Any of these problems can result in downtime and lost or damaged resources. Understanding the nature of a threat is insufficient to prevent it from occurring.
At the same time, remember that you do not need many special precautions or special software to protect against programmed threats. The same simple, effective measures you would take to protect your system against unauthorized entry or malicious damage from insiders will also protect your system against these other threats.
Files, directories, and devices that are writable (world-writable) by any user on the system can be dangerous security holes. An attacker who gains access to your system can gain even more access by modifying these files, directories, and devices. Maintaining a vigilant watch over your file protections protects against intrusion and also protects your system's legitimate users from each other's mistakes and antics. ( Chapter 5 introduces file permissions and describes how you can change them.)
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.
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.
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.
Programs that depend on shared libraries are vulnerable to a variety of attacks that involve switching the shared library that the program is running. If your system has dynamic libraries, they need to be protected to the same level as the most sensitive program on your system, because modifying those shared libraries can alter the operation of every program.
On some systems, additional shared libraries may be specified through the use of environment variables. While this is a useful feature on some occasions, the system's shared libraries should not be superseded for the following kinds of programs:
Programs executed by SUID programs
User shells
Network servers
Security services
Auditing and logging processes
On some versions of UNIX , you can disable shared libraries by statically linking the executable program. On others, you can limit whether alternate shared libraries are referenced by setting additional mode bits inside the executable image. We advise you to take these precautions when available.