I-0041: Object Reuse Applies To All System Resources

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

TITLE:                Object Reuse Applies To All System Resources
APPROVAL POSTING:     [announce 0357]

EFFECTIVE:            1994-04-19

REQUIREMENT:          Object Reuse
CRITERIA CLASSES:     C2, B1, B2, B3, A1
DOCUMENT(S):          <None>
RELATED TO:           <None>

STATEMENT:

The following interprets all of the Object Reuse requirement.

Analysis for residual data shall be performed on all sharable objects and their attributes (i.e., objects to which MAC or DAC are applied) and other system resources (e.g., stacks, process memory).

PROJECTED IMPACT:

Negligible impact anticipated.

SUPPORT:

Shared objects and the subject's address space are possible vehicles for carrying residual data from one subject to another subject. Global pools of resources, where by individual resources are serially allocated to one subject and then returned to the global pool, require careful examination. For shared objects, all of the object's attributes must also be examined, because their access control and method of eliminating residual data may be different than those for the object itself.

Three types of residual data exist: subject-created data with no TCB understood semantics (e.g., file contents), subject-created data with TCB understood semantics (e.g., filenames in a directory), and TCB-created data whose value the subject can influence (e.g. the modification-time attribute of a file). Not eliminating residual data in the first type can result in a direct transfer of information from one subject to another, with no intention on the part of the sending subject (or even the receiving subject). The second and third type can result in a direct transfer of information (e.g. names of files could be useful information); however, they are probably more useful for encoding information (i.e., used as a covert channel), which would usually require intention on the part of the sender and receiver.

The second and third type of residual data are often overlooked in an object reuse analysis. For example, devices have attributes that are readable, and sometimes writable, by a subject while allocated. Some of these attributes may not be reset to a standard configuration value in all situations when the device is returned to the global pool. Since these attributes have TCB-understood semantics and will not contain random residual user data, they are an example of either the second or third type.

The analysis for residual data must use the abstractions supported at the TCB interface. For example, one of the visible abstractions of many products is files, although the implementation internal to the TCB may involve segments or buffer caches.

TCB internal data structures have, at times, been considered as a factor contributing to residual data. Some products have had residual data problems because, even though they cleared shared objects and the subject's address space at creation, the TCB, as part of its execution of a subject, moved data left over from a previous subject in a TCB internal data structure to a shared object or another subject's address space. Such actions are not examples of an object reuse problem; however, they are an example of a lack of process separation or TCB isolation.