A System Break-In Scenario

Before we explain the other security features, here is some background information on system security that should help you understand why they are necessary.

Many problems with UNIX security hinge on a UNIX file attribute called the suid (set user ID) bit. This is like a permission bit (see umask earlier in this chapter): when an executable file has it turned on, the file runs with an effective user ID equal to the owner of the file, which is usually root. The effective user ID is distinct from the real user ID of the process.

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

This feature lets administrators write scripts that do certain things that require root privilege (e.g., configure printers) in a controlled way. To set a file's suid bit, the superuser can type chmod 4755 filename; the 4 is the suid bit.

Modern system administration wisdom says that creating suid shell scripts is a very, very bad idea.[13] This has been especially true under the C shell, because its .cshrc environment file introduces numerous opportunities for break-ins. bash's environment file feature creates similar security holes, although the security feature we'll see shortly make this problem less severe.

We'll show why it's dangerous to set a script's suid bit. Recall that in Chapter 3, we mentioned that it's not a good idea to put your personal bin directory at the front of your PATH. Here is a scenario that shows how this placement combines with suid shell scripts to form a security hole: a variation of the infamous "Trojan horse" scheme. First, the computer cracker has to find a user on the system with an suid shell script. In addition, the user must have a PATH with her personal bin directory listed before the public bin directories, and the cracker must have write permission on the user's personal bin directory.

Once the cracker finds a user with these requirements, he follows these steps:

 

 
  • Looks at the suid script and finds a common utility that it calls. Let's say it's grep.
  • Creates the Trojan horse, which is this case is a shell script called grep in the user's personal bin directory. The script looks like this:

    cp /bin/bash filename
                         chown root 
                         filename
                         chmod 4755 
                         filename
                         /bin/grep "$@
    rm ~/bin/grep

    filename should be some unremarkable filename in a directory with public read and execute permission, such as /bin or /usr/bin. The file, when created, will be that most heinous of security holes: an suid interactive shell.

  • Sits back and waits for the user to run the suid shell script—which calls the Trojan horse, which in turn creates the suid shell and then self-destructs.
  • Runs the suid shell and creates havoc.