Red Hat Linux 7 Unleashed

Red Hat Linux 7 Unleashed

By

Danger, Will Robinson, Danger!

I used to love watching Lost in Space. On that show was a life-sized robot that would declare, "Danger, Will Robinson, danger!" when there was some danger. Unfortunately, no such robot warns of danger on our systems. (Although some tools exist, they are nowhere near as consistent as that robot was!)

If you have a lot of extra disk space, you can turn on auditing, which records all user connects and disconnects from your system. If you don't rely on auditing, you should scan the logs often. A worthwhile alternative might be to write a quick summary script that reports the amount of time each user is on the system.

Unfortunately, there are too many holes to block them all. Measures can be placed to plug the biggest, but the only way to keep a system secure is by locking a computer in a vault, allowing no one access to it and no connectivity outside the vault. The bottom line is that users who want into your system and who are good enough can get in. What you have to do is prepare for the worst.

Preparing for the Worst

The three things that a malicious user can do to a system—short of physically removing it—are stealing data, destroying data (which includes making it inaccessible), and providing easier access for the next time he wants to get into the system. Physically, an intruder can destroy or remove equipment or, if very creative, even add hardware. Short of chaining the system to the desk, retinal scans, card readers, and armed guards, there is not much you can do to prevent theft. Physical security is beyond the scope of this book. What is within the scope of this book is dealing with the data and dealing with additional access measures.

Data should be backed up on a regular basis. The backed-up information, depending on how secure it needs to be, can be kept on a shelf next to the system or in a locked vault at an alternate location. A backup is the best way of retrieving data that has been destroyed.

Most of the time, though, data is not just destroyed. A more common problem is that the data is captured. This could include actual company secrets or system configuration files. Keeping an eye on the system files is very important. Another good idea is 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, so that later searches can be compared to this initial list.

suid and sgid

Many people talk about suid (set user ID) and sgid (set group ID) without clearly understanding them. The concept behind these powerful and dangerous tools is that a program (not a script) is set to run as the owner or group set for the program—not as the person running the program. For example, say you have a program with suid set, and its owner is root. Users running the program run that program with the permissions of the owner instead of their own permissions. The passwd command is a good example of this. The /etc/passwd file is writable by root and readable by everyone. The passwd program has suid turned on; therefore, anyone can run the passwd program and change her password. Because the program is running as the user root, not as 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 associated with the program.

How to Find suid and sgid Files

The find command once again comes in handy. You can search the entire system with the following command, looking for programs with their suid or sgid turned on:


   $ find / -perm -2000 -o -perm -4000 -print

Running the preceding find command when you first load a system is probably best, 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 to ensure that only the files that are supposed to have these permissions really do. With the current release of Red Hat Linux (version 7), there are approximately 30 files that have either suid or sgid set, and have either the owner or group of root.

Setting suid and sgid

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 if a user has 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:

  • Use the lowest permissions needed to accomplish the task.
  • Watch for back doors.

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 accomplishes the same task while limiting other potential problems.

Back doors come in many forms. A program that allows a shell is a back door. Multiple entrances and exits to a program 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 (users can get out of the program to a prompt without actually exiting the program), the system keeps the effective user ID as what the program is set to (root). 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? How do you set a file to have 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 for 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.

Share ThisShare This