| Previous | Table of Contents | Next |
The I&A Components Must Be Trustworthy
Often, in large networks you will find that various software products are responsible for a different range of I&A services. The example given previously for database versus operating system user names is a classic division of responsibility. Both management domains require a storage location for the user names, one or more programs to maintain the I&A information, and interfaces for other security components to request I&A services or information.
Both the database manager and the operating system are responsible for I&A within a particular security context. A database user name has no meaning within the context of the operating system. Likewise, the user names stored in the operating system’s repository are generally irrelevant for gaining access to databases controlled by the database manager. Products installed at your site are responsible for security only within specific contexts. A firewall has little to do with rules controlling which records in the payroll database someone can access.
The parts of a security product that are used to provide I&A services play a pivotal role in networked environments. Every entity must be able to be uniquely identified. Furthermore, the integrity of the software or hardware used in I&A must be guaranteed. Any mechanisms or procedures used to create, delete, or change I&A information must meet the requirements of the reference monitor. That is, I&A software or hardware must be complete, verifiable, and capable of being isolated. The reasons are quite simple. If the I&A process can be subverted or spoofed, then the reference monitor cannot guarantee that the security policy is enforced. Also, if you cannot uniquely identify entities in the computing environment, you will have difficulty assigning accountability for actions or regulating access control.
The security model now includes subjects, objects, a subsystem for identifying and authenticating these entities, and a reference monitor for controlling access between entities. Earlier discussions made reference to an authorization database used by the reference monitor for making decisions about access requests by subjects. In this section, access control is added to the other components in the security model. Access control is further divided into discretionary access control and mandatory access control.
Discretionary Access Control
Discretionary access control (DAC) is the type most frequently seen. Commercial UNIX systems as well as NT rely on DAC. In systems based on discretionary access, the owner of the object is responsible for setting the access rights. As a side effect of many operating system designs, one or more privileged users also can change access rights for an object. A DAC implementation needs to be granular enough so that the owner can specify access control down to the level of an individual user or group. You should be able to state individual users or groups as subjects in the first field of the access control database entry.
Mandatory Access Control
Rather than relying on the owner of an object to control access rights, mandatory access control (MAC) uses the system itself to regulate access rights. The object’s owner does not even have the capability to assign access rights to other subjects or users in the system. The system controls access rights based on how subjects and objects are classified. In addition to the normal string of characters identifying the entity, such as a user name or file name, each subject or object is tagged with a sensitivity label consisting of two parts:
The access class label is chosen from a predefined, hierarchically ordered set of labels. Commonly found labels in military security policies include top secret, secret, confidential, and unclassified. Each label represents a level of information that is more restrictive than the previous label. Order is important. The labels cannot be arbitrary tags that have no relationship to each other. A precedence relationship must state, for example, that top secret is at a higher level than secret, that secret precedes confidential, and that confidential is more restrictive than unclassified. The purpose of labeling is to prevent a user who is classified at only the confidential level from accessing information at the secret or top secret level. Another property of MAC is that you cannot “write down” information or declassify it to a lower level in the system. If a disk file is classified as confidential, MAC will prevent anyone from writing secret or top secret information into the file.
Category labels are arbitrary tags that are not required to be hierarchically arranged. The category labels can be thought of as compartments. In many situations today, we must compartmentalize information. The military has long used compartmentalization to ensure that information is given out only to those with a “need to know.”
Users, as well as other subjects and objects, can be associated with many category labels, but they may have only one access class label. MAC enforces accesses based on these sensitivity labels. Returning to the two basic access primitives, read and write, MAC works as follows: To read an object, the access class of the subject must be equal to or greater than the access class of the object, and the list of category labels for the subject must be a superset of (contain) the list of category labels for the object; to write an object, the subject’s access class label must be equal to or less than that of the object, and all of the subject’s category labels must be included in the list of category labels for the object.
This concept may seem confusing at first, but if you think about it, the rules make perfect sense. Consider access labels first. When reading from an object, you obviously must be cleared at a security level at least as high as that of the object. If your label is confidential, you cannot read information classified higher than confidential. Also, if the object is tagged with several categories, and you are not allowed to access all of these categories, you should not be allowed to read from the object. To prevent downgrading of information, writing to an object requires that you be classified at no more than the classification level of the object. If your classification is top secret, you might be able to write top secret information into a file classified at a lower level. The write rule is designed to prevent this from happening.
| Previous | Table of Contents | Next |