I-0003: Access Validation After Object Label Change

NUMBER:               I-0003
STATUS:               Approved by CCEVS Management and Mailed to Public Mailing
                      List

TITLE:                Access Validation After Object Label Change
APPROVAL POSTING:     [announce 0390]

EFFECTIVE:            1994-11-16

REQUIREMENT:          Mandatory Access Control
CRITERIA CLASSES:     B1, B2, B3, A1
DOCUMENT(S):          Trusted Facility Manual; Security Features Users Guide
RELATED TO:
     I-0001           Delayed Enforcement Of Authorization Change
     I-0002           Delayed Revocation Of DAC Access
     I-0004           Enforcement Of Audit Settings Consistent With Protection Goals
     I-0239           Subject Access Revocation After Change In User Clearance

STATEMENT:

The following interprets the entire MAC requirement and applies only if the TCB provides an interface for changing an object's label.

The MAC policy shall be enforced with respect to the new label for all data written to the object after the label change is completed successfully. The label change shall be considered complete when an access control check would be made with respect to the new value of the label; this shall occur no later than when an indication of completion is returned by the TCB to the agent (e.g., user, process) requesting the change. The TFM, and SFUG, if appropriate, shall describe the effects of label changes on access to objects. It is not acceptable for access changes resulting from object label changes to be enforced only through procedural means.

PROJECTED IMPACT:

Most evaluated products meet this interpretation.

SUPPORT:

Products that permit object labels to be changed, by methods specified in the TFM, are still required to enforce at all times their MAC policy on defined storage objects; however, a number of mechanisms or restrictions would be satisfactory methods of enforcement. For example, the TCB could satisfy this requirement by preventing changes to an object's label while any subject has active access (e.g., possesses a descriptor for the object), or preventing the label change only if it would result in an active subject acquiring access not permitted by the MAC policy. Another acceptable, and more versatile and secure, enforcement mechanism would be to recalculate each subject's access when the label is changed, or, less flexibly, simply to revoke access for all subjects. The point is that the MAC policy must be continuously enforced: object label changes must not permit access that violates the policy.

``Procedural'' in this context means that the TFM describes a step-by-step process for changing an object label. If the procedure is not followed correctly illegal information flows could occur.

A naive view of revocation would be that a subsequent "read" or "fetch" from the object must fail if the subject's label does not dominate the object's new label. In practice, buffering makes this analysis complex, because data may have been copied (by the TCB) between the object's "permanent" storage representation and buffers from which the "read" operation actually retrieves data. For instance, if an operating system implements read-ahead for files, or reads a block at a time, a sequence of user-visible "read" operations requesting one byte at a time may succeed even though the real object's label has changed. Similarly, in a DBMS, a "select" operation may identify a set of tuples and create a logical copy of the set from which individual tuples can be fetched.

In all cases, however, the critical issue is that subsequent information flows must be prevented after the label change. If the following sequence of operations occurs:

Object contains "A"
Subject1 opens object
File label changes so that subject1 can no longer read it
Subject2 writes "B" to file

a subsequent "read" by subject1 may result in an error, or may validly return "A", because those were the contents before the label change, but it MUST NOT return "B", because that would make visible a change of contents that occurred after the label change.

In most products, such buffering and concurrency control issues have little practical effect, because it is important to maintain consistency between different subjects' views of an object--if not immediately, then usually within a granularity of a few seconds or a few thousand bytes. In products such as DBMSs, however, where subjects exercise explicit control over consistency and concurrency, the window of inconsistent access may be significantly larger, because consistency is of greater concern to applications. The size of the window is not an issue, as long no invalid flows occur after the label change is committed. The documentation (TFM, SFUG) should describe the effects of access changes so that administrators and users can understand the risks of changing labels.

Because some object label changes may be under the control of untrusted users, it is critically important to the MAC policy that the TCB enforce that the change be effective. Automatic enforcement of the label change is necessary because it would be infeasible to rely on procedures for protection against active attack (manipulation) of the objects by untrusted subjects. For example, in a system where an untrusted user is permitted to upgrade an object, it would be unreasonable to depend on that user to block all access to the object, then check for other subjects with current access to it, before making the label change. Yet, if that procedure were not followed, an existing subject might retain access to the object, and thus be able to violate the system's MAC policy.

In many instances, trusted users who are given the privilege to downgrade are not system administrators, but are either system security officers or security officers for a particular application domain. They may have little understanding of the product and therefore have difficulty following a procedure or recovering from mistakes. Without the aid of the TCB even system administrators would find it very difficult on most systems to change the level of an object on an actively running system and ensure that no window of opportunity for illegal access exists without the aid of the TCB; therefore, procedural means are not sufficient.

The TCB may provide multiple means for trusted users to change object labels, some of which do not enforce the MAC policy. This may be acceptable, subject to other requirements (e.g., system architecture, trusted facility management), as long as the TFM advises use of the MAC policy enforcing mechanisms and explains the risk of using the non-MAC policy enforcing mechanisms.