C.2. Rating by the Book
As discussed earlier, a security policy states the rules enforced by the system to provide the necessary degree of security. The Orange Book defined the following specific requirements in the security policy category:
What's a Trusted System?
The Orange Book talked about "trusted" systems rather than "secure" systems. The words aren't really synonymous. No system is completely secure. Any system can be penetratedgiven enough tools and enough time. But systems can be trusted, some more than others, to do what we want them to do, and what we expect them to continue to do over time.
The Orange Book provided its own definition of a trusted system, and the language lingers to this day:
. . . a system that employs sufficient hardware and software integrity measures to allow its use to simultaneously process a range of sensitive unclassified or classified (e.g., confidential through top secret) information for a diverse set of users without violating access privileges.
The concept of the Trusted Computing Base is central to the notion of a trusted system. The Orange Book used the term TCB to refer to the mechanisms that enforce security in a system. The book defined the TCB as follows:
The totality of protection mechanisms within a computer systemincluding hardware, firmware, and softwarethe combination of which is responsible for enforcing a security policy. It creates a basic protection environment and provides additional user services required for a trusted computer system. The ability of a trusted computing base to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user's clearance) related to the security policy.
Not every part of an operating system needs to be trusted. An important part of an evaluation of a computer system is to identify the architecture, assurance mechanisms, and security features that comprise the TCB, and to show how the TCB is protected from interference and tamperingeither accidentally or deliberately.
An Orange Book rating, even a very high rating, can't guarantee security. A "trusted" system is still only as secure as the enforcement of that system. Much of actual system security is in the hands of your system administrator and/or your security administrator. Your administrative staff must understand the full range of system features, must set up all necessary security structures, and must train users to do their part. Often, their efforts will seem toothless unless high management lends them weight. The more highly trusted a system is, the less individual users can compromise the system. But system administration remains the vital link between a system's theoretical security and its actual ability to function securely in the real world.
C.2.1. Discretionary and Mandatory Access Control
The discretionary access control method restricts access to files (and other system objects) based on the identity of users and/or the groups to which they belong. DAC is the most common type of access control mechanism found in trusted systems.
The DAC requirement specifies that users should be able to protect their own files by indicating who can and cannot access them (on a "need-to-know" basis) and by specifying the type of access allowed (e.g., read-only, read and modify, etc.). In contrast to mandatory access control, in which the system controls access, DAC is applied at the discretion of the user (or a program executing on behalf of the user). With DAC, you can choose to give away your data; with MAC, you can't.
C.2.2. Object Reuse
Object reuse requirements protect files, memory, and other objects in a trusted system from being accidentally accessed by users who aren't authorized to access them. Consider a few obvious examples of what could happen if object reuse features are not part of a trusted system. Suppose that when you create a new file, your system allocates a certain area of disk to that file. You store confidential data in the file, print it, and eventually delete it. However, suppose the system doesn't actually delete the data from the physical disk, but simply rewrites the header of the file to indicate deletion. There are many ways to bypass ordinary system procedures and read the data on the disk without using the normal filesystem. Object reuse features provide security by ensuring that when an objectfor example, a login IDis assigned, allocated, or reallocated, the object doesn't contain data left over from previous usage.
Common object reuse features implemented in trusted systems include:
Clearing memory blocks or pages before they are allocated to a program or data.
Clearing disk blocks when a file is scratched or before the blocks are allocated to a file.
Degaussing magnetic tapes when they're no longer needed.
Clearing X Window System objects before they are reassigned to another user.
Erasing password buffers after encryption.
Clearing buffered pages, documents, or screens from the local memory of a terminal or printer.
A sensitivity label describes briefly who can access what information in your system. Labels and mandatory access control are separate security policy requirements, but they work together. Beginning at the B1 level, the Orange Book required that every subject (e.g., user, process) and storage object (e.g., file, directory, window, socket) have a sensitivity label associated with it. (For B2 systems and above, all system resources (e.g., devices, ROM) must have sensitivity labels.) A user's sensitivity label specifies the sensitivity level, or level of trust, associated with that user; a user's sensitivity label is usually called a clearance. A file's sensitivity label specifies the level of trust that a user must have to be able to access that file.
C.2.3.1. Label integrity
Label integrity ensures that the sensitivity labels associated with subjects and objects are accurate representations of the security levels of these subjects and objects. Thus, a file sensitivity label, such as:
TOP SECRET [VENUS]
must actually be associated with a TOP SECRET file containing information about the planet Venus. A clearance, such as:
COMPANY CONFIDENTIAL [PAYROLL AUDIT]
must be assigned to an accountant who's responsible for the payroll and auditing activities in your company. Similarly, when information is exported (as discussed in the next few sections), the sensitivity label written on the output must match the internal labels of the information exported.
Suppose that a user edits a TOP SECRET file to remove all TOP SECRET and SECRET information (leaving only UNCLASSIFIED information), and then changes the sensitivity label to UNCLASSIFIED. If the system crashes at this point, has it ensured that the label didn't get written to disk before the changes to the file were written? If such a thing could happen, you'd end up with a file labeled UNCLASSIFIED that actually did contain TOP SECRET dataa clear violation of label integrity. Systems rated at B1 and above must prove that their label integrity features guard against such violations.
C.2.3.2. Exportation of labeled information
A trusted system must be sure that when information is written by the system, that information continues to have protection mechanisms associated with it. Two important ways of securing exported information are to assign security levels to output devices and to write sensitivity labels along with data. Systems rated at B1 and above must provide secure export facilities.
The Orange Book defined two types of export devices: multilevel and single-level. Every I/O device and communications channel in a system must be designated as one type or the other. Any changes to these designations must be able to be audited. Typically, a system administrator designates devices during system installation and setup.
Exportation to multilevel devices
A multilevel device or a multilevel communications channel is one to which you can write information at a number of different sensitivity levels. The system must support a way of specifying the lowest (e.g., UNCLASSIFIED) and the highest (e.g., TOP SECRET) security levels allowed for data being written to such a device.
To write information to a multilevel device, the Orange Book required that the system have some way to associate a security level with it. Mechanisms may differ for different systems and different types of devices. Files written to such devices must have sensitivity levels attached to them (usually written in a header record preceding the data in the file). This prevents a user from bypassing system controls by simply copying a sensitive file to another, untrusted system or device. Of course, there must be system controls on what devices can actually be used in this wayand what happens to the transferred data. A sensitivity label on a file isn't much protection if a user can simply carry a CD home, or can post the file to a web page. In most trusted systems, only disks are categorized as multilevel devices.
Exportation to single-level devices
A single-level device or a single-level communications channel is one to which you can write information at only one particular sensitivity level. Usually, terminals, printers, tape drives, and communication ports are categorized as single-level devices. The level you specify for a device is usually dependent on its physical location or the inherent security of the device type. For example, your installation might locate printers in a number of different computer rooms and offices. You'd designate these printers as having sensitivity levels corresponding to the personnel who have access to the printers.
You might designate a printer in a public area as UNCLASSIFIED, whereas a printer in a highly protected office used only by an individual with a TOP SECRET clearance might be designated TOP SECRET. Once you've designated a device in this way, the system will be able to send to that device only information at the level associated with the device.
Unlike output sent to multilevel devices, output sent to single-level devices is not required to be labeled with the security level of the exported information, although many trusted systems do label such output. The Orange Book does require that there be some way (system or procedural) to designate the single level of information being sent to the device.
Labeling human-readable output
The Orange Book included very clear requirements for how to label hard-copy output (output that people can see). This included pages of printed output, maps, graphics, and other displays. The system administrator must have some way of specifying the labels that appear on the output.
C.2.3.3. Subject sensitivity labels
The subject sensitivity label requirement states that the system must notify a terminal user of any change in the security level associated with that user during an interactive session. This requirement applies to systems rated at B2 and above.
The idea of subject sensitivity labels is that you must always know what security level you're working at. Trusted systems typically display your clearance when you log in, and redisplay it if the security level changes, either automatically or at the user's request.
C.2.3.4. Device labels
The device labels requirement states that each physical device attached to your system must have minimum and maximum security levels associated with them, and that these levels are used to "enforce constraints imposed by the physical environments in which the devices are located."