19.5 Protecting the root Account

Some Unix systems offer additional methods of protecting the root account:

Secure terminals
The wheel group
The sudo program

A few systems provide an additional set of features, known as a trusted path and a trusted computing base (TCB). We'll describe all of these features in the following sections.

19.5.1 Secure Terminals

Because every Unix system has an account named root, this account is often a starting point for people who try to break into a system by guessing passwords. One way to decrease the chance of such break-ins is to restrict logins from all but physically guarded terminals. If a terminal is marked as restricted, the superuser cannot log into that terminal from the login: prompt. (However, a legitimate user who knows the superuser password can still use the su command on that terminal after first logging in.)

On an SVR4 machine, you can restrict the ability of users to log into the root account from any terminal other than the console. You accomplish this by editing the file /etc/default/login and inserting the line:

CONSOLE=/dev/console

This line prevents anyone from logging in as root on any terminal other than the console. If the console is not safe, you may set this to the pathname of a nonexistent terminal.

Linux and some BSD-derived versions of Unix allow you to declare terminal lines and network ports as either secure or not secure. You declare a terminal secure by appending the word "secure" to the terminal's definition in the file /etc/ttys:^[9]

^[9] Under SunOS and some other versions of Unix, this file is called /etc/ttytab; under Linux, it's /etc/securetty (and is simply a list of terminals on which root can log in, including entries like "vc/1" which refer to the first virtual console window provided by the Linux text-based console system). Some older versions of BSD store the list of secure ports in the file /etc/securettys.

tty01 "/usr/etc/getty std.9600" vt100 on secure
tty02 "/usr/etc/getty std.9600" vt100 on

In this example taken from an /etc/ttys file, terminal tty01 is secure and terminal tty02 is not. This means that root can log into terminal tty01 but not tty02.

Note that after changing the /etc/ttys file, you may need to send out a signal to init before the changes will take effect. On a BSD-derived system, run:

# kill -1 1

Other systems vary, so check your own system's documentation.^[10]

^[10] Declaring network ports as not secure generally prevents connections using protocols that call the login program (such as Telnet), but may not prevent root from connecting using protocols that bypass login entirely. Fortunately, the most useful of such protocols, SSH, is usually implemented so that you can prevent root SSH logins with a configuration file entry.

You should carefully consider which terminals are declared secure. Many sites, for example, make neither their dial-in modems nor their network connections secure; this prevents intruders from using these connections to guess the system's superuser password. Terminals in public areas should also not be declared secure. Being "not secure" does not prevent a person from executing commands as the superuser: it simply forces users to log in as themselves and then use the su command to become root. This method adds an extra layer of protection and accounting, and many administrators declare all of their terminals as "not secure" for this reason.

On the other hand, if your computer has a terminal in a special machine room, you may wish to make this terminal secure so you can quickly use it to log into the superuser account without having to log into your own account first.

Many versions of Unix require that you type the superuser password when booting in single-user mode if the console is not listed as "secure" in the /etc/ttys file. Obviously, if you do not mark your console "secure," you enhance your system's security.

19.5.2 The wheel Group

Another mechanism that further protects the root account is the wheel group. A user who is not in the wheel group cannot use the su command to become the superuser. Be very careful about who you place in the wheel group; on some versions of Unix, people in the wheel group can provide their own passwords to su—instead of the superuser password—and become root.

19.5.3 The sudo Program

The sudo program, which is included with several Linux distributions and MacOS X, and can be installed on any Unix system, takes another approach to the problem of the root account that is particularly suitable when several people are responsible for system administration. Instead of giving all of the administrators the superuser password (and thus turning root into a group account), the administrators use the sudo command to run programs as root. sudo prompts for the user's password, rather than the root password.

The strength of sudo lies in its ability to restrict which commands a user can run and to log every command run by sudo. For example, it can be used to permit a user to run only the dump command as root to perform a system backup. The logging facility provides greatly increased accountability for superuser commands.

The potential downside of sudo, of course, is that the accounts of users who are permitted to run commands as root must, in most cases, be protected as strongly as the superuser account.

19.5.4 Trusted Path and Trusted Computing Base

When you are worried about security, you want to ensure that the commands you execute are the real system commands and not something designed to steal your password or corrupt your system. Some versions of Unix have been augmented with special features to provide you with this additional assurance.

19.5.4.1 Trusted path

Consider the case in which you approach a terminal and wish to log into the system. What if someone has left a program—a Trojan horse program (see Chapter 23)—running on the terminal? If the program has been designed to capture your password by presenting a prompt that looks like the real login program, you might not be able to tell the difference until the damage is done. If the program has been very carefully crafted to catch signals and otherwise mimic the login program behavior, you might not catch on at all. And if you are not using one-time passwords (described later in Section 19.6), you may be giving someone else access to your account.

The solution to this is to provide a trusted path to the login program from your terminal. Some Unix systems can be configured to recognize a special signal from hardwired terminals (including workstation consoles) for this purpose. When the signal (usually a BREAK, or some sequence of control characters) is received by the low-level terminal driver, the driver sends an unstoppable signal to all processes still connected to the terminal that terminates them. Thereafter, a new session is started and the user can be assured that the next prompt for a login is from the real system software.

For a trusted-path mechanism to work, you must have a hardwired connection to the computer: any networked connection can be intercepted and spoofed.^[11] The system administrator must enable the trusted-path mechanism and indicate to which terminal lines it should be applied. As this may require reconfiguring the kernel and rebooting (to include the necessary terminal code), you should carefully read your vendor documentation for instructions on how to enable this feature.

^[11] Network logins have other potential problems, such as password sniffing. As we've made clear elsewhere in this book, plaintext passwords should not be transmitted over a network. Use SSH or another encrypting protocol instead.

If your system provides the trusted-path mechanism and you decide to use it, be sure to limit superuser logins to only the associated terminals!

19.5.4.2 Trusted computing base

After you have logged in, you may be faced with situations in which you are not quite certain if you are executing a trusted system command or a command put in place by a prankster or intruder. If you are running as the superuser, this uncertainty is a recipe for disaster, and is why we repeatedly warn you throughout the book to leave the current directory out of your search path, and to keep system commands protected.

Some systems can be configured to mark executable files as part of the TCB. Files in the TCB are specially marked by the superuser as trusted. When you're running a special trusted shell, only files with the TCB marking can be executed with exec( ). Thus, only trusted files can be executed.

How do files get their trusted markings? New files and modified TCB files have the marking turned off. The superuser can mark new executable files as part of the TCB; on some systems, this process can be done only if the file was created with programs in the TCB. In theory, an attacker who is not already the superuser will not be able to mark Trojan files as part of the TCB, and thus the superuser cannot accidentally execute dangerous code.

This feature is especially worthwhile if you are administering a multiuser system, or if you tend to import files and filesystems from other, potentially untrusted, systems. However, you must keep in mind that the marking does not necessarily mean that the program is harmless. The superuser can mark files as part of the TCB, and some of those files might be dangerous. Thus, remember that the TCB, as with every other feature, only reinforces overall security rather than guarantees it.