In addition to explicit access by users to objects, security must also be supplied to the information within the objects. Some objects (eg, files) have information that is more secure than other objects. Information must be prevented from flowing from this more secure object to a less secure one. This also is applicable to users as objects -- a user without the necessary access level should not have secure information flowing to him.
There are two main ways to implement this idea. One is through bit vectors, essentially an array of bits. The other is assigning a class number to the object.
An example of a bit vector is: |
|
This bit vector represents the compartments an object sits in. Each bit represents one compartment. A "1" indicates the object is in the compartment, a "0" indicates it isn't. In order to be able to read the object, the user must possess a bit vector which is a subset of the object's bit vector. To write to the object, the user's bit vector must be a superset of the object's.
The other way of implementing this idea is through security classes. A security class is a number in some range (say 1 to 10) which descibes the level of security on the object. Each object possesses a security class. For a user to read an object, the user's security class must be greater than that of the object's. This means the information in the object is of a lower security than the user's level, so the system can allow information to flow from the object to the user. If the user's security class is less than that of the object's, the user can write to the object.
This goes above and beyond the access restrictions supplied by access control lists or capabilities. For systems with a need for a great amount of security, a better system is needed. Priviledged information should not always be dissemated by the information owner's say alone. By assigning a security class or a compartment list to an object, secure information can be prevented from flowing to the wrong places, no matter what the information owner wants.