5.3 Tranquility

The principle of tranquility states that subjects and objects may not change their security levels once they have been instantiated. Suppose that security levels of objects can be changed, and consider the effects on a system with one category and two security clearances, HIGH and LOW. If an object's security classification is raised from LOW to HIGH, then any subjects cleared to only LOW can no longer read that object. Similarly, if an object's classification is dropped from HIGH to LOW, any subject can now read that object.

Both situations violate fundamental restrictions. Raising the classification of an object means that information that was available is no longer available; lowering the classification means that information previously considered restricted is now available to all. In essence, the LOW subjects either have, or have had, access to HIGH information, in violation of the simple security condition. Furthermore, by lowering the classification level, the HIGH subjects lose the ability to append to the object, but anything they have written into the object becomes available at the LOW level, and so this has the effect of writing to an object with a lower classification and thereby violates the *-property.

Raising the classification of an object is not considered a problem. The model does not define how to determine the appropriate classification of information. It merely describes how to manipulate an object containing the information once that object has been assigned a classification. Information in an object with a particular classification is assumed to be known to all who can access that object, and so raising its classification will not achieve the desired goal (preventing access to the information). The information has already been accessed.

Lowering the classification level is another matter entirely and is known as the declassification problem. Because this makes information available to subjects who did not have access to it before, it is in effect a "write down" that violates the *-property. The typical solution is to define a set of trusted entities or subjects that will remove all sensitive information from the HIGH object before its classification is changed to LOW.

The tranquility principle actually has two forms:

Definition 5–9. The principle of strong tranquility states that security levels do not change during the lifetime of the system.

Strong tranquility eliminates the need for trusted declassifiers, because no declassification can occur. Moreover, no raising of security levels can occur. This eliminates the problems discussed above. However, stong tranquility is also inflexible and in practice is usually too strong a requirement.

Definition 5–10. The principle of weak tranquility states that security levels do not change in a way that violates the rules of a given security policy.

Weak tranquility moderates the restriction to allow harmless changes of security levels. It is more flexible, because it allows changes, but it disallows any violations of the security policy (in the context of the Bell-LaPadula Model, the simple security condition and *-property).

EXAMPLE: In the Data General DG/UX system, only the security administrator, a trusted user, can change MAC labels on objects. In general, when a user wishes to assume a new MAC label, that user must initiate a new session; the MAC labels of processes cannot be changed. However, a user may be designated as able to change a process label within a specified range. This makes the system more amenable to commercial environments.

Tranquility plays an important role in the Bell-LaPadula Model, because it highlights the trust assumptions in the model. It raises other problems in the context of integrity that we will revisit in the next chapter.