cification. This book describes systems it has evaluated in terms of different protection levels, from weakest to strongest, including:
Class D, which are systems that do not pass any tests and are therefore untrusted. No sensitive data should be stored on class D systems.
Class C1, which are systems that require authentication based on a user model.
Class C2, which are systems that provide auditing and logging on a per-user basis, ensuring that file accesses and related operations can always be traced to the initiating user.
Class B1, which requires security labeling for all files. Labels range from “top secret” to “unclassified.”
Class B2, which separates normal system administration duties from security activities that are performed by a separate security officer. This level requires covert channels for data communications and verified testing of an installation’s security procedures.
Class B3, which requires that a stand-alone request monitor be available to authenticate all requests for file and resource access. In addition, the request monitor must be secured and all of its operations logged.
Class A1, which is a formally tested and verified installation of a class B3 system.
All of the strategies that we discuss in this chapter are focused on increasing the number of layers through which a potential cracker (or disgruntled staff member) must pass to obtain the data that they are illegally trying to access. Reducing the threat of remote access exploits and protecting data are key components of this strategy.
It may seem obvious—if an intruder can physically access your system, then he or she may be able to take control of your system without the root password, bypassing all of the software-based controls that normally limit such activity. How is this possible, you might ask? If the intruder has access to a bootable CD-ROM drive, and a bootable CD-ROM (of Solaris, Linux, or any other operating system that can mount UFS drives), it’s trivial to enter the following command at the OpenBoot prompt and start the system without a password:
ok boot cdrom
Once the system has booted from the CD-ROM drive, a number of options are available to the intruder:
Do an ftp on any file on the system to a remote system.
Copy any file on the system to a mass storage device (such as a DAT tape).
Format all of the drives on the system.
Launch a distributed denial of service attack against other networks, which you will be blamed for.
Of course, the possibilities are endless, but the result is the same. You may ask why it is so easy to compromise a system in this way: one good reason is that if you forget your root password, you can boot from the CD-ROM, mount the boot disk, and manually edit the shadow password file.
This requirement doesn’t really excuse poor security, and the OpenBoot monitor provides some options to secure the system. There are three security levels available:
None Surprisingly, this is the default. No password is required to execute any of the commands in OpenBoot. This is convenient but dangerous, for the reasons outlined earlier.
Command This level needs a password to be entered for all commands except boot and go. Thus, details of the SCSI bus and network traffic can’t be observed by the casual browser, but an intruder could still boot from the CD-ROM.
Full This level requires a password for every command except go, including the boot command. Thus, even if the system is interrupted and rebooted using the boot command, only the default boot device will be available through go.
To set the security level, the eeprom command is used. To set the command level, use the following command:
# eeprom security-mode=command
Alternatively, to set the command level, use the following command:
# eeprom security-mode=full
The password for the command and full security levels must be set by using the eeprom command:
# eeprom security-password= Changing PROM password: New password: Retype new password:
Note that if the root password and the full-level password are lost, there is no way to recover the system by software means: a ne