Rescue Mode

Rescue mode is an environment you can use to fix a system that does not boot normally. To bring a system up in rescue mode, boot the system from the rescue CD, the first installation CD, or the installation DVD. From the rescue CD, at the boot: prompt press RETURN without entering a command. Give the command linux rescue in response the boot: prompt from the first installation CD or the installation DVD. The system then comes up in rescue mode. The boot process may take several minutes.

In rescue mode, you can change or replace configuration files, check and repair partitions using fsck (page 470), rewrite boot information, and more. The rescue setup first asks if you want to set up the network interface. This interface is required if you want to copy files from other systems on the LAN or download files from the Internet. When you choose to set up the network interface, you need to choose whether to have DHCP automatically configure the network connection or to manually supply the IP address and netmask of the interface, as well as the IP addresses of the gateway and up to three DNS addresses.

If the rescue setup finds an existing Linux installation, you can choose to mount it under /mnt/sysimage, optionally in readonly mode. With the existing installation mounted, once the system displays a shell prompt (similar to sh-3.1#), you can give the command chroot /mnt/sysimage to mount the existing installation as it would be if you booted normally, with the existing installation's root mounted at / (root). (See page 428 for more information on chroot.) If you choose not to mount the existing installation, you are running a rescue system with standard tools mounted in standard locations (/bin, /usr/bin, and so on). Partitions from your local installation are available for fixing or mounting. When you exit from the rescue shell, the system reboots. Remove the CD or DVD if you want to boot from the hard drive.

Avoiding a Trojan Horse

A Trojan horse is a program that does something destructive or disruptive to a system while appearing to be benign. As an example, you could store the following script in an executable file named mkfs:

while true        do        echo 'Good Morning Mr. Jones. How are you? Ha Ha Ha.' > /dev/console        done

If you are running as Superuser when you run this command, it would continuously write a message to the console. If the programmer were malicious, it could do worse. The only thing missing in this plot is access permissions.

A malicious user could implement this Trojan horse by changing Superuser's PATH variable to include a publicly writable directory at the start of the PATH string. (The catch is that you need to be able to write to /etc/profilewhere the PATH variable is set for rootand only root can do that.) Then you would need to put the bogus mkfs program file in that directory. Because the fraudulent version appears in a directory mentioned earlier than the real one in PATH, the shell runs it. The next time Superuser tries to run mkfs, the fraudulent version would run.

Trojan horses that lie in wait for and take advantage of the misspellings that most people make are among the most insidious types. For example, you might type sl instead of ls. Because you do not regularly execute a utility named sl and you may not remember typing the command sl, it is more difficult to track down this type of Trojan horse than one that takes the name of a more familiar utility.

A good way to help prevent the execution of a Trojan horse is to make sure that your PATH variable does not contain a single colon (:) at the beginning or end of the PATH string or a period (.) or double colon (::) anywhere in the PATH string. This precaution ensures that you will not execute a file in the working directory by accident. To check for a possible Trojan horse, examine the filesystem periodically for files with setuid (refer to item 5 on page 392) permission. The following command lists these files:

Listing setuid files

# find / perm 4000 exec ls lh {} \; 2> /dev/null rwsrxrx 1 root root 13K Feb 12 00:18 /sbin/pam_timestamp_check rwsrxrx 1 root root 22K Feb 12 00:18 /sbin/unix_chkpwd rwsrxrx 1 root root 84K Feb 12 12:38 /bin/mount rwsrxrx 1 root root 61K Feb 12 12:38 /bin/umount rwsrxrx 1 root root 25K Feb 10 22:43 /bin/su rwsrxrx 1 root root 36K Feb 11 15:06 /bin/ping rwsrxrx 1 root root 32K Feb 11 15:06 /bin/ping6 rwsxx 1 root root 37K Feb 12 10:43 /usr/sbin/userhelper ...

This command uses find to locate all files that have their setuid bit set (mode 4000). The hyphen preceding the mode causes find to report on any file that has this bit set, regardless of how the other bits are set. The output sent to standard error is redirected to /dev/null so that it does not clutter the screen.

You can also set up a program, such as AIDE (Advanced Intrusion Detection Environment), that will take a snapshot of your system and check it periodically as you specify. See sourceforge.net/projects/aide for more information.

Getting Help

The Red Hat Linux distribution comes with extensive documentation (page 102). Red Hat maintains a page that points you toward many useful support documents: https://www.redhat.com/apps/support. You can also find help on the System Administrators Guild site (www.sage.org). The Internet is another rich source of information on managing a Linux system; refer to Appendix B (page 977) and to the author's home page (www.sobell.com) for pointers to useful sites.

You do not need to act as a Red Hat system administrator in isolation; a large community of Linux/Red Hat experts is willing to assist you in getting the most out of your system, although you will get better help if you have already tried to solve a problem yourself by reading the available documentation. If you are unable to solve a problem by consulting the documentation, a well-thought-out question to the appropriate newsgroup, such as comp.os.linux.misc, or mailing list can often generate useful information. Be sure you describe the problem accurately and identify your system carefully. Include information about your version of Red Hat Enterprise Linux or Fedora Core and any software packages and hardware that you think relate to the problem. The newsgroup comp.os.linux.answers contains postings of solutions to common problems and periodic postings of the most up-to-date versions of FAQs and HOWTO documents. See www.catb.org/~esr/faqs/smart-questions.html for a good paper by Eric S. Raymond and Rick Moen titled "How to Ask Questions the Smart Way."