 | Chapter 8 Defending Your Accounts |  |
| Chapter 8 Defending Your Accounts | |
Versions of UNIX that are derived from Berkeley UNIX systems provide two additional methods of protecting the root account:
Secure terminals
The wheel group
A few systems provide an additional set of features, known as a trusted path and a trusted computing base (TCB).
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 this 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 a SVR4 machine, you can restrict the ability of users to log in to 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/consoleThis 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.
Some older Berkeley-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:[5]
[5] Under SunOS and some other versions of UNIX, this file is called /etc/ttytab. 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 a /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 initialize 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.
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.
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 first to log into your own account.
NOTE: 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.
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.
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.
Consider the case where we approach a terminal and wish to log in to the system. What is a potential problem? What if someone has left a program - a Trojan Horse[6] program - running on the terminal? If the program has been designed to capture our password by presenting a prompt that looks like the real login program, we 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, we might not catch on at all. And if you are not using one-time passwords (described later in Section 8.7, "One-Time Passwords), you may be giving someone else access to your account.
[6] Trojan Horse programs are defined in more detail in Chapter 11, Protecting Against Programmed Threats.
The solution to this is to provide a trusted path to the login program from our terminal. Some UNIX systems, including AIX and Ultrix, 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.[7] The system administrator must enable the trusted path mechanism and indicate to which terminal lines it is to be applied. As this may require reconfiguring your kernel and rebooting (to include the necessary terminal code), you should carefully read your vendor documentation for instructions on how to enable this feature.
[7] Network login have other potential problems, such as password sniffing.
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!
After we've logged in, we may be faced with situations where we are not quite certain if we are executing a trusted system command or a command put in place by a prankster or intruder. If we 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 trusted computing base (TCB). Files in the TCB are specially marked by the superuser as trusted. When 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 only be done if the file was created with programs in the TCB. In theory, an attacker will not be able to be superuser, (or set the marking on files) 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. As the superuser can mark files as part of the TCB, some of those files might be dangerous. Thus, remember that the TCB, like any other feature, only reinforces overall security.
|  | |
| 8.4 Managing Dormant Accounts |  | 8.6 The UNIX Encrypted Password System |