Any person who is able to access the computer can press the Reset button, and thus reboot it. Then, at the bootloader's prompt, it is possible to pass the init=/bin/sh option to the kernel to gain root access without knowing the administrator's password.
To prevent this, you can protect the bootloader itself with a password. You might also think about protecting access to the BIOS (a password protection mechanism is almost always available), without which a malicious intruder could still boot the machine on a removable media containing its own Linux system, which they could then use to access data on the computer's hard drives.
Finally, be aware that most BIOS have a generic password available. Initially intended for troubleshooting for those who have forgotten their password, these passwords are now public and available on the Internet (see for yourself by searching for “generic BIOS passwords” in a search engine). All of these protections will thus impede unauthorized access to the machine without being able to completely prevent it. There's no reliable way to protect a computer if the attacker can physically access it; they could dismount the hard drives to connect them to a computer under their own control anyway, or even steal the entire machine, or erase the BIOS memory to reset the password…
BACK TO BASICS Kernel modules and options
Kernel modules also have options that can be configured by putting some files in /etc/modprobe.d/. These options are defined with directives like this: options module-name option-name=option-value. Several options can be specified with a single directive if necessary.
These configuration files are intended for modprobe — the program that loads a kernel module with its dependencies (modules can indeed call other modules). This program is provided by the module-init-tools package.
After this stage, init takes over and starts the programs enabled in the default runlevel (which is usually runlevel 2). It executes /etc/init.d/rc 2, a script that starts all services which are listed in /etc/rc2.d/ and whose name start with the “S” letter. The two-figures number that follows had historically been used to define the order in which services had to be started. In Squeeze, the default boot system uses insserv, which schedules everything automatically based on the scripts' dependencies. Each boot script thus declares the conditions that must be met to start or stop the service (for example, if it must start before or after another service); init then launches them in the order that meets these conditions. The static numbering of scripts is therefore no longer taken into consideration (but they must always have a name beginning with “S” followed by two characters and the actual name of the script used for the dependencies). Generally, base services (such as logging with rsyslog, or port assignment with portmap) are started first, followed by standard services and the graphical interface (gdm).
This dependency-based boot system makes it possible to automate re-numbering, which could be rather tedious if it had to be done manually, and it limits the risks of human error, since scheduling is conducted according to the parameters that are indicated. Another benefit is that services can be started in parallel when they are independent from one another, which can accelerate the boot process.
ALTERNATIVE Other boot systems
This book describes the boot system used by default in Debian (as implemented by sysvinit package), which is derived and inherited from System V Unix systems, but there are others.
In the original System V, and in versions of Debian up to Lenny, the execution order of initialization scripts was defined only by the names of the /etc/rc*.d/S* symbolic links (and /etc/rc*.d/K* upon shutdown). This behavior can be re-established by setting CONCURRENCY=none in the /etc/default/rcS file.
file-rc is another boot system with a very simple process. It keeps the principle of runlevels, but replaces the directories and symbolic links with a configuration file, which indicates to init the processes that must be started and their launch order
The newly arrived upstart system is still not perfectly tested on Debian. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent. This system, started by Ubuntu, is present in Debian Squeeze, but is not the default; it comes, in fact, as a replacement for sysvinit, and one of the tasks launched by upstart is to launch the scripts written for traditional systems, especially those from the sysv-rc package.
Another new option is systemd, but it still lacks the maturity needed to be part of Squeeze. Its approach is opposite to the previous systems; instead of preemptively launching all services, and having to deal with the question of scheduling, systemd chooses to start services on demand, somewhat along the principle of inetd. But this means that the boot system must be able to know how services are made available (it could be through a socket, a filesystem, or others), and thus requires small modifications of those services.
There are also other systems and other operating modes, such as runit, minit, or initng, but they are relatively specialized and not widespread.
init distinguishes several runlevels, so it can switch from one to another with the telinit new-level command. Immediately, init executes /etc/init.d/rc again with the new runlevel. This script will then start the missing services and stop those that are no longer desired. To do this, it refers to the content of the /etc/rcX.d (where X represents the new runlevel). Scripts starting with “S” (as in “Start”) are services to be started; those starting with “K” (as in “Kill”) are the services to be stopped. The script does not start any service that was already active in the previous runlevel.
By default, Debian uses four different runlevels:
Level 0 is only used temporarily, while the computer is powering down. As such, it only contains many “K” scripts.
Level 1, also known as single-user mode, corresponds to the system in degraded mode; it includes only basic services, and is intended for maintenance operations where interactions with ordinary users are not desired.
Level 2 is the level for normal operation, which includes networking services, a graphical interface, user logins, etc.
Level 6 is similar to level 0, except that it is used during the shutdown phase that precedes a reboot.
Other levels exist, especially 3 to 5. By default they are configured to operate the same way as level 2, but the administrator can modify them (by adding or deleting scripts in the corresponding /etc/rcX.d directories) to adapt them to particular needs.
Figure 9.1. Boot sequence of a computer running Linux
All the scripts contained in the various /etc/rcX.d directories are really only symbolic links — created upon package installation by the update-rc.d program — pointing to the actual scripts which are stored in /etc/init.d/. The administrator can fine tune the services available in each runlevel by re-running update-rc.d with adjusted parameters. The update-rc.d(1) manual page describes the syntax in detail. Please note that removing all symbolic links (with the remove parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since update-rc.d has a somewhat convoluted interface, you may prefer using rcconf (from the rcconf package) which provides a more user-friendly interface.