So far, we have examined the essential features of Solaris security, including the need to protect individual files (as well as entire systems) from unauthorized access. In addition, we examined how both files and systems can be protected from remote access tools. However, we need to place these individual actions within a context that logically covers all aspects of security, typically known as levels. A level is an extra “step” that must be breached in order to obtain access to data.
In terms of physical security, a bank provides an excellent analogy. Breaking into a bank’s front counter and teller area is as easy as walking through the door, because these doors are publicly accessible. However, providing this level of access sometimes opens doors deeper inside the building. For example, the private banking area, which may normally only be accessed by staff and identified private banking customers, may allow access using a smart card. If a smart card is stolen from a staff member, it could be used to enter the secure area, because the staff member’s credentials would be authenticated. Entering this level would not necessarily provide access to the vault: superuser privileges would be required. However, a thorough physical search of the private banking area might yield the key required for entry. Alternatively, a brute force attack on the safe’s combination might be used to guess the correct combination. Having accessed the vault, if readily negotiated currency or bullion is contained therein, then an intruder could easily steal them. However, if the vault contained checks that needed to be countersigned, the intruder may not be able to make use of the contents. The lesson here is simple: banks provide public services that open up pathways straight to the cash. Banks know that any or all of the physical security layers may be breached. That’s why the storage of negotiable securities is always minimized, because any system designed by humans can be broken by humans, with enough time and patience. The only sensible strategy is to make sure that external layers are as difficult to breach as possible, and to ensure that security experts are immediately notified of breaches.
Similarly, public file areas, such as FTP and WWW servers, are publicly accessible areas on computer systems that sometimes provide entry to a different level in the system. An easily guessed or stolen password may provide user-level (but unprivileged) access to the system. A brute force attack against the local password database might even yield the superuser password. Accessing a local database might contain the target records of interest. However, instead of storing the data plaintext within tables, data may have been written using a stream cipher, making it potentially very difficult to obtain the data. And because 40-bit ciphers have been broken in the past, obtaining the encrypted data might eventually lead to its dissemination. Again, a key strategy is ensuring that data is secure by as many external layers as possible, and also that the data itself is difficult to negotiate.
Increasing the number of levels of security typically leads to a decrease in system ease of use—for example, setting a password for accessing a printer requires users to remember and enter a password when challenged. Whether or not printer access needs this level of security will depend on organizational requirements. For a printer that prints on plain paper, no password may be needed. However, for a printer that prints on bonded paper with an official company letterhead, a password should be used to protect the printer, and optionally, a copy of the file being sent to the printer may need to be stored securely for auditing purposes.
For government and military systems, there are a number of security specifications and policy documents available, which detail the steps necessary to secure Solaris systems in “top secret” installations. The U.S. Department of Defense, for example, publishes the Orange Book, formally known as the “Trusted Computer System Evaluation Criteria” spe