The Object Reuse Guide is the latest in a series of technical guidelines published by the National Computer Security Center. These publications provide insight to the Trusted Computer System Evaluation Criteria requirements for the computer security vendor and technical evaluator. The goal of the Technical Guideline Program is to discuss each feature of the Criteria in detail and to provide the proper interpretations with specific guidance.
The National Computer Security Center has established an aggressive program to study and implement computer security technology. Our goal is to encourage the widespread availability of trusted computer products for use by any organization desiring better protection of its important data. One way we do this is by the Trusted Product Evaluation Program. This program focuses on the security features of commercially produced and supported computer systems. We evaluate the protection capabilities against the established criteria presented in the Trusted Computer System Evaluation Criteria. This program, and an open and cooperative business relationship with the computer and telecommunications industries, will result in the fulfillment of our country's information systems security requirements. We resolve to meet the challenge of identifying trusted computer products suitable for use in processing information that requires protection.
I invite your suggestions for revising this technical guideline. We will review this document as the need arises.
We wish to thank the many members of the computer security community who enthusiastically gave their time and technical expertise in reviewing this guideline and providing valuable comments and suggestions.
The TCSEC was originally published on 15 August 1983 as CSC-STD-001 -83. In December 1985 the Department of Defense adopted it, with a few changes, as a Department of Defense Standard, DoD 5200.28-STD. DoD Directive 5200.28, Security Requirements for Automated Information Systems (A 155) [4], requires the TCSEC be used throughout the Department of Defense. The TCSEC is the standard used for evaluating the effectiveness of security controls built into DoD ASs.
The TCSEC is divided into four divisions: D, C, 19, and A. These divisions are ordered in a hierarchical manner, with the highest division (A) being reserved for systems providing the best available level of assurance and security. Within divisions C and 19 are subdivisions known as classes, which are also ordered in a hierarchical manner to represent different levels of security in these divisions.
In this guideline, "classified" means any information requiring protection or authorization to access. The disclosure arising from the absence of an object reuse mechanism is considered inadvertent (assuming all other TCSEC requirements are in place and working properly).
The requirement ultimately derives from observations made during the early penetration testing experiences (circa 1969-1973) that systems typically did not clear a user s working memory (often called "scratch space") when the user completed a session. Thus, when memory was reassigned to another user, the information placed in it by the previous user was now available to the new owner of the scratch space. Often, the disclosure was inadvertent: the second user had not intended to obtain the information suddenly made available. However, it also meant that a malicious (or just curious) user could browse (or "scavenge") through the system, obtaining scratch space and looking for items of interest (the equivalent of rummaging through the trash). Depending upon the details of the system architecture and operating system, a browser could more or less control whose work space was being accessed. Although the problem was first noted as one involving primary storage (or main memory), it clearly extends to secondary storage as well; removable media (such as tapes and removable disks) and disk space must be allocated such as to prevent one user s information from inadvertently becoming available to others as system storage resources are shared among system users.
In short, with effective object reuse mechanisms in place, a penetrator is prevented from obtaining information through browsing attacks (e.g., logging onto the system as a user and browsing). Object reuse does not necessarily protect against physical attacks on the storage medium, especially using sophisticated equipment and methods (e.g., taking a degaussed disk pack and trying to read residual information from the platters). Protection against physical attacks are addressed by A Guide to Understanding Data Remanence in Automated Information Systems [1].
The requirement does not specify how to perform object reuse. It allows the designer some leeway in implementation. An obvious approach is to clear the storage, either upon deallocation or at allocation. Either method is acceptable in meeting the requirement, although there are tradeoffs to consider when making this choice. These issues are discussed later in this guideline. However, the designer can use an approach which, in effect, guarantees that the current "owner' of the storage can only access what he has written (e.g., preventing the reading beyond the end-of-file mark on a tape or in a disk block). Thus, the wording of the requirement recognizes the existence of different implementation strategies which accomplish the same end.
The first sentence of the requirement ("All authorizations to the information contained within a storage object shall be revoked....") means that once a storage object is given to a user, no subject can have access to the information which had been (or may still be) in that object. "All authorizations to the information contained within a storage object shall be revoked...." does not equate to "no subject can have access to that object's contents."Nor does it equate to revoking the authorization attributes (e.g., read, write, execute or append) assigned to information within a storage object. Why? Because if the vendor chooses to clear the storage object "prior to initial assignment, allocation or reallocation," he has revoked "all authorizations to the information contained within [the] storage object." The focus is on the information ---not the storage object, not the attributes.
Does object reuse require the revocation of authorization attributes (e.g., read, write, execute or append) assigned to information within a storage object before it is assigned or allocated? It depends upon the particular implementation. Suppose a system uses memory segments with read, write, execute, and append attributes encoded into descriptors. If the information in the segment has been overwritten, there is no need to clear the descriptor unless the descriptor is considered part of the storage object or is itself a storage object which is released to the system. If the descriptor is considered a storage object or part of one, the attributes are information subject to the object reuse requirement. In both cases, the system could overwrite the old attributes with the new user's attributes. Or it could remove all attributes at deallocation. Either way, clearing the attributes only assures that granting access to a pooled storage object (in this case, a segment) does not implicitly give access to any data previously contained in the object. The information within the storage object must still be protected from the new owner.
Consider the case when a parent process initiates one or more subordinate processes, each having access to a file owned by the parent. Suppose the parent process deletes the file, and the file space (disk space, for example) is returned to the system's resource pool. Does proper object reuse also require the removal of the subordinate processes' access permissions to the file space upon deallocation? No, the requirement allows the system to leave the access set to the parent and/or the offspring processes, but only tO those proCesses. This guarantees that no other processes can access the information in the workspace until the proper procedures are followed. The requirement does not say "revoke authorizations at deallocation of storage objects" ---the requirement does not care if access is continued to be allowed to the process that caused the information to appear in the storage object before the object is reassigned. In other words, a subject could retain effective access to an object that had been returned to the "free pool" until that object was reallocated. (Note: We can think of no reason for, nor an actual implementation of, the above approach. We mention it only to make a point.)
Strictly speaking, the TCSEC object reuse requirement only applies to storage objects accessible by untrusted users of an AIS. However, the system designer may choose to ensure that internal Security relevant data structures are also properly cleared when reusing the internal object. This internal data structure clearing may occur via explicit action of the Trusted Computing Base (TCB), or it may be implicit via a complete overwrite with new TCB data.
An example which illustrates these issues is shown using Table 1. In this example, a segmented memory system provides for virtual storage to system users, using a segment map table (SMT) to maintain segment control information. Control of access to the storage object (i.e., memory segment) is effected by setting the appropriate access attributes to 1 (access permitted) or 0 (access not permitted). Thus, an SMT description pertaining to a segment allocated to subject 51 for read/write access would reflect an attribute coding of R = 1, W = 1, IE = 0, and A = 0 (or 1100).
To satisfy the TCSEC object rouse requirement, the TCB must perform several different actions with respect to the segment and the SMT. The TCB must ensure that the segment is accessible only through known, TCB controlled, mechanisms such as the SMT. This assures the invocation of the TCB whenever an access decision must be made. The TCB must not permit access (by a new subject) to the segment until the segment is specifically allocated to a subject. The TCB must ensure the segment is clear (i.e., contains no residual data) either by explicitly clearing the segment at allocation, clearing the segment at deallocation, or completely over- writing the segment with new data which the subject assigned the segment is permitted to access in the assigned mode. The TCB must also ensure the clearing of any residual control information (i.e., internal TCB data structure) before reallocating
Table 1: SEGMENT MAP TABLE DESCRIPTION
-----------------------------------------------------------------------------------
Resident Secondary Attribute Real
Bit Storage Length Address
Address R W E A
-----------------------------------------------------------------------------------
-----------------------------------------------------------------------------------
the segment (if the control information is contained within a storage object). For example, if SMTs are considered storage objects, the TCB must ensure the clearing of any secondary SMT entries for a segment.
CPU Registers
Floating Point Co-processor
Registers
Cache Memory
Physical Memory
Disk Blocks/Sectors
Magnetic Tape Blocks/Sectors
Floppy Disk
Table 2: Common Physical Objects
Storage objects are virtualized into objects that are visible to system users. Some common user objects are discussed in the following section, along with a description of the storage objects used to implement the object.User Object - Object Implementation
Virtual Memory - Virtual memory is implemented using structures similar to the SMT shown in Figure 1, and physical memory segments and pages. The TCB maintains the structures defining the allocation of physical memory to users. Virtual segments and pages correspond to the physical segments and pages when the virtual memory is mapped into physical memory. Otherwise, the virtual memory resides in a temporary storage area of a physical disk drive or other secondary media.
Files - Files are typically an abstraction of virtual memory and disk blocks or sectors. When a file is not being accessed, it is commonly stored on a physical disk drive. The file is defined by a control block which stores the security critical information of the file and identifies the data blocks corresponding to the file. The control and data blocks are physically resident on the disk drive and are maintained by the TCB. When the file is being accessed, all or part of the file is mapped into the virtual address space (virtual memory) of the process (subject) accessing the file.
Directories - Directories are a special type of file that contains information regarding files. Directories reflect the names of files, and upon referring to a specific filename, the directory provides information to the TCB regarding the physical disk location of the file control block.
Virtual Tape Drives - Tapes drives are generally available to users in one of two fashions: allocating the entire tape drive to a user, or providing access to the tape drive through files (as if the tape drive were a disk drive). When a tape drive is completely allocated to a user, the user can utilize the tape drive in whatever manner desired, so long as the system security policy is adhered to. When a tape drive is accessed through files, the TCB maintains the information relevant to properly protect the files from unauthorized access. This requires the TCB to maintain control and data block information, just as is maintained for files on disk drives.
The object reuse requirement applies to the storage objects defined on an AIS system. But, as is seen in the previous discussion regarding the implementati0ff of virtual objects, it is essential to consider completely what storage objects are used to define the system's objects. By carefully considering this visible object - storage object correspondence the system designer ensures the fulfillment of the object reuse requirement in the AIS system.
Reference [5] proposes a reasonable methodology in conducting an object reuse study. This process is paraphrased here as a representative guide of how one might approach the problem during system development.
Step 1: Identify system objects by focusing on the system documentation that completely describes the TCB interface. This will contain the vast majority of the needed information. If a model exists for the system's security policy, the objects should be contained within it. If not, the remaining system documentation and its architecture should be useful in developing a list of object types.
Step 2: Determine what system level objects are used to create the user-visible objects identified in step 1 above. This is the critical step in the methodology and may represent the greatest amount of analysis. Done correctly, this step determines the bounds of the study. The analysis requires an indepth understanding of the specific operating system involved and knowledge of exactly how user objects are represented.
Step 3: For each identified component, determine how the system initially creates, recognizes, allocates, and deallocates it and returns it for system use. Inherent in this procedure is the need to verify that the requirements originally stated for object reuse processing are met for initialization/allocation or allocation/deallocation, and that the two are equal. The remaining steps provide this assurance.
Step 4: Examine each system object's initialization routine to ensure that the requirements of object reuse are being met when an object is added to the system. That is, ensure it contains no residual information.
Step 5: Examine the allocation/deallocation routines to ensure that the requirement to remove residual information has been met.
Step 6: Identify all the system operations used to allocate/deallocate objects and ensure that each invokes the object reuse mechanisms necessary to provide the required protection listed in steps three through five above. (Note ---do not forget operations that "only" extend, shorten, or move objects, as these are also allocation/deallocation operations worthy of scrutiny.)
Step 7: Ensure that the free pool of objects itself is protected so that unpurged objects cannot be accessed and read prior to their reallocation. If the system chooses to implement object reuse upon reallocation, there may be a lengthy period of vulnerability where the object with residual information is stored in the free pool. The free pool must guarantee protection of the information so it remains secure until purged prior to reallocation.
Object reuse is essential for all storage objects available in an AS, but an examination of those objects listed in Table 2 reveals that not all such objects are always under TCB control. For example, the TCB can completely control the ability to access data stored in physical memory but cannot protect data stored on magnetic tapes and floppy disks which have been removed from the system. These removable media are subject to mistakes made by operators, and the media may be removed by system users and accessed using off-site equipment. In either of these cases, the TCB does not protect the data stored on the media and must rely to some extent upon physical, procedural, or other controls to ensure that data is not inappropriately accessed or altered. These controls must be discussed in the Trusted Facility Manual for the system. These classes of objects are depicted in Figure 2, where the cache and main memory is normally always under TCB control, the non- removable (fixed) media is usually under TCB control, and removable media is often not under TCB control.
Figure 2: STORAGE OBJECT CONTROL
Removable Media Fixed Media Main Memory - Real & Virtual Cache Memory Fully Under TCB Control Usually Under TCB Control Often Not Under TCB Control
One must not forget to handle registers. A common error made by system designers is to forget to clear registers that are new to the product or infrequently used by system programmers (e.g., floating point co-processor registers).
Cache memory may present a slightly different set of considerations. If a file is deleted by its owner and portions of the file are retained in cache memory, a later request for information contained in the cache may be honored even though the file no longer exists (unless proper design safeguards are established). This is especially true if the second request occurs very soon after file deletion.
When primary memory is removed from the system (e.g., for maintenance or repair), it is subject to the same considerations discussed later for removable media.
Data is typically stored and retrieved from these kinds of media through the use of several control mechanisms ---each of which might be a storage object in its own right. For example, if a fixed disk or drum is used to provide a backing store capability for a paging system, there are likely several objects associated with the fixed media that will have object reuse requirements. The physical data blocks themselves must be paged between usages, but in addition to this obvious requirement, one must also consider purging the associated entry for the page in the system's page management table and also purging directory information that resides on the media itself.
In all cases, the TCB's ability to fully assure object reuse processing must be demonstrated. This is normally accomplished as discussed earlier in this guideline, through the identification of all objects (and their components) and an examination of each of the routines that control initialization, allocation, and deallocation. As with primary memory, fixed media which is removed from the system is subject to the same considerations discussed later for removable media.
To ensure the system is started in an initially-secure state, the fixed reusable medium must be initialized to an appropriate condition. Clearly, the extent Of the initialization depends on the type of fixed storage objects involved: main memory storage units must be initialized each time a trusted system is started up, while longer-term storage (e.g., disks) would have to be initialized only on first startup or perhaps as part of a recovery process after a system failure.
One can design systems and their attached devices (printers, terminals, etc.) that have residual memory to be cleared with a command issued by the main processor's TCB. However, for open architectures, there is little that can be done from a TCB to (re)initialize the equipment for reallocation. One technique that works with some equipment is to power it off, then on. However, such practice is hard on the equipment and is sometimes not possible without modifying the equipment, or providing TCB-controlled power (outlets) for the equipment. The more likely approach for connected terminal equipment having its own processing capability is to ensure the terminal device itself enforces the object reuse requirement.
First, any of the methods used for fixed medium systems can be used. As in the fixed storage class, it is important to overwrite in complete physical allocation units (e.g., sectors, clusters, blocks, tracks, cylinders). The actual allocation units are operating system dependent.
As an example, one logical method may apply to tape storage. If the system being rated has no 1/0 commands accessible to users that can force the reading of a tape beyond an end-of-file (IEOF) mark, the TCB can write an EOF mark at the beginning of all `scratch' tapes. Of course, the question is what informs the TCB that a scratch tape is being introduced to the system. As will be seen below, this is a specific instance of a more general question of how to reintroduce removable media to the control of the TCB.
In general, overwriting storage is feasible if the amount of storage to be overwritten is relatively small, and the overwriting is relatively fast. Thus, for most `main memory' usage, overwriting is feasible. It is also feasible for diskettes and other small removable disk media, such as disk cartridges, especially if a multiprogrammed daemon owned by the TCB performs the overwriting.
If real-time overwriting is not feasible (a case for most large removable storage media), then some off-line method is indicated. Only two physical methods appear suitable: degaussing (demagnetizing) and independent off-line overwriting. This guideline cannot recommend any specific degausser, although Government- approved degaussers are available. One commercially available model can completely degauss up to 10 tapes, or a removable disk, in one operation (which takes less than 30 seconds). Degaussers that have been approved to degauss classified tapes or disks are listed on the NSA Degausser Products List [3]. The actual procedures used for degaussing are beyond the scope of this guideline because they again are not processes a TCB can control.
On-line overwriting is a method the TCB could control, possibly by not releasing a tape for removal or reallocation until its entire length is overwritten. However, the performance impact of using on-line overwrite alone is so onerous that it is not a practical solution. Perhaps an efficient method of handling off-line overwrite is to dedicate a small computer system to that function, with one or more tape or disk drives to hold the medium being prepared for reuse. If off-line overwriting is done, there is a lingering concern over whether the overwrite is complete. Even if off-line overwriting is an extension of the object reuse mechanism, one may have to verify the overwrite mechanism always overwrote the entire medium.
With removable media, the TCB must be informed in some manner that a new or reprocessed (degaussed or off-line overwritten) storage object is being introduced into the allocable storage object pool. Further, since there may be an arbitrary time lapse between a medium being accepted for reuse and its actual reuse, the TCB needs some way to identify removable storage objects that have been accepted for reuse. This is certainly a candidate for incorporation into the system's Trusted Facility Manual.
Clearly, something like the ". . . mechanism by which the TCB and an authorized user reliably communicate . . "to designate the single level of information being imported or exported via single-level communications or 1/0 devices could be adapted to allow an operator to reliably inform the TCB that a new or reprocessed removable medium is being reintroduced into the pool of allocable storage objects. At the lower classes the mechanism might be the operator's console. At higher level classes, it might be a variant on the Trusted Path mechanisms between users and the TCB.
How the TCB identifies the removable storage object as being accepted for reuse is again a detail that is very system-dependent. It could range from TCBreadable physical identification numbers recorded on the medium being entered into a TCB-managed and -controlled inventory file, to the TCB magnetically (or optically) recording on the medium an encrypted serial number which it also keeps in the inventory of available allocable storage objects.
If degaussing is used as the off-line process to prepare a removable storage object for reuse, it is likely the operating system must prepare it for use by writing timing tracks or sector addresses and by performing other low-level formatting of the medium without which the medium can not be used by the system. This may be sufficient assurance that the TCB has a chance to identify the storage object. However, the TCB must still maintain the inventory of allocable storage objects and assure that only previously accepted storage objects are allocated. As a consequence, it is recommended that formatting of degaussed media is done as a separate function not associated with reentering the medium into the pool of allocable storage objects, and the acceptance and identification process be completely separate from any media preparation required by the system.
While there is no requirement to apply such a technique to all removable media, the notion of economy of mechanism suggests it would be easier to understand if all removable reusable storage is handled in the same way.
If real-time overwriting of removable storage is not practical, overwrite it off-line or degauss it. Dedicating a small computer system to overwrite storage off-line is an efficient method. When degaussing is used, do not connect media formatting with reentering the media into the pool of allocable storage objects. Separate the acceptance and identification process from media preparation. Handle all removable storage the same way. Incorporate this into the system's Trusted Facility Manual.
Managing the reintroduction of media to the TCB is a problem with off-line object reuse preparation. The TCB must know it is ailocating a properly processed object. For fixed media, the TCB largely controls the process, and design verification assures that the TCB allocates properly processed objects. With removable media, the TCB is told when new or reprocessed storage objects are put into the storage object pool. How this is done is very system-dependent.