Page 401
Most of the time, though, data is not just destroyed. A more common problem is that the data is captured. This could be actual company secrets or system configuration files. It is very important to keep an eye on the system files. It is also a good idea to occasionally search for programs that have suid or sgid capability. It might be wise to search for suid and sgid files when the system is first installed. Then, later searches can be compared to this initial list.
Many people talk about suid (set user ID) and sgid (set group ID) without really understanding them. The concept behind these powerful, yet dangerous, tools is that a program (not a script) is set so that it is run as the owner or group set for the program, not the person running the program. For example, say you have a program with suid set, and its owner is root. Anyone running the program runs that program with the permissions of the owner instead of his or her own permissions. The passwd command is a good example of this. The file /etc/passwd is writable by root, and readable by everyone. The passwd program has suid turned on. Therefore, anyone can run the passwd program and change their password. Because the program is running as the user root, not the actual user, the /etc/passwd file can be written to.
The same concept holds true for sgid. Instead of the program running with the permissions and authority of the group associated with the person calling the program, the program is run with the permissions and authority of the group that is associated with the program.
The find command once again comes in handy. With the following command, you can search the entire system looking for programs with their suid or sgid turned on:
find / -perm -200 -o -perm -400 -print
It is probably best to run the preceding find command when you first load a system, saving its output to a file readable only by root. Future searches can be performed and compared to this "clean" list of suid and sgid files. This will ensure that only the files that are supposed to have these permissions really do.
The set user ID and set group ID can be powerful tools for giving users the ability to perform tasks without the other problems that could arise with the user having the actual permissions of that group or user. However, these can be dangerous tools as well. When considering changing the permissions on a file to be either suid or sgid, keep in mind these two things:
Using the lowest permissions means not giving a file an suid of root if at all possible. Often, a less privileged person can be configured to do the task. The same goes for sgid. Many times setting the group to the appropriate non-sys group will accomplish the same task while limiting other potential problems.
Page 402
Back doors come in many forms. A program that allows a shell is a back door. A program that has multiple entrances and exits are back doors. Keep in mind that if a user can run an suid program set to root and the program contains a back door (the user can get out of the program to a prompt without actually exiting the program), then the system keeps the effective user ID as what the program is set to (root), and the user now has root permissions.
With that said, how do you set a file to have the effective user be the owner of the file, or the effective group be the group of the file, instead of running as the user ID or the user's group ID of the person invoking the file? The permissions are added with the chmod command, as follows:
chmod u+s file(s) chmod g+s file(s)
The first example sets suid for the file(s) listed. The second example sets sgid to the file(s) listed. Remember, suid sets the effective ID of the process to the owner associated with the file, and sgid sets the effective group's ID of the process to the group associated with the file. These cannot be set on nonexecutables.
As stated in the introduction to this chapter, file and directory permissions are the basics for providing security on a system. These, along with the authentication system, provide the basis for all security. Unfortunately, many people do not know what permissions on directories mean, or they assume they mean the same thing they do on files. The following section describes the permissions on files; after that, the permissions on directories are described.
The permissions for files are split into three different sections: the owner of the file, the group associated with the file, and everyone else (the world). Each section has its own set of file permissions. These permissions provide the ability to read, write, and execute (or, of course, to deny the same). These permissions are called a file's filemode. Filemodes are set with the chmod command.
There are two ways to specify the permissions of the object. You can use the numeric coding system or the letter coding system. Using the letter coding system, the three sections are referred to as u for user, g for group, and o for other or a for all three. There are three basic types of permissions: r for read, w for write, and x for execute. Combinations of r, w, and x with the three groups provide the permissions for files. In the following example, the owner of the file has read, write, and execute permissions, while everyone else has read access only:
shell:/home/dpitts$ ls -l test -rwxr--r-- 1 dpitts users 22 Sep 15 00:49 test
The command ls -l tells the computer to give you a long (-l) listing (ls) of the file (test). The resulting line is shown in the second code line, and it tells you a number of things about