 |
A GUIDE to UNDERSTANDING OBJECT REUSE in TRUSTED SYSTEMSPatrick R. G r, Jr. July 1992Director National Computer Security Center Table of Contents
ACKNOWLEDGMENTS 1 INTRODUCTION 2 OVERVIEW OF PRINCIPLES
2.2 PURPOSE OF THE OBJECT REUSE REQUIREMENT 2.3 APPLICABILITY OF THE OBJECT REUSE REQUIREMENT 2.4 SUMMARY
3.2 FIXED MEDIA METHODS 3.3 REMOVABLE MEDIA METHODS 3.4 MANAGEMENT OF REMOVABLE MEDIA 3.5 SUMMARY REFERENCES
FOREWORDA Guide to Understanding Object Reuse in Trusted Systems provides a set of good practices related to object reuse. We have written this guideline to help the vendor and evaluator communities understand the requirements for object reuse as described in the Department of Defense Trusted Computer System Evaluation Criteria. In an effort to provide guidance, we make recommendations in this technical guideline that are not requirements in the Criteria.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.
ACKNOWLEDGMENTSThe National Computer Security Center extends special recognition and acknowledgment to James Anderson, COL Rayford Vaughn (USA), and Rick Siebenaler as authors of this document. Patricia R. Toth is recognized for the development of this guideline, and Capt. James A. Muysenberg (USAF) is recognized for its editing and publication.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.
1 INTRODUCTION1.1 BACKGROUNDThe principal goal of the National Computer Security Center (NCSC) is to encourage the widespread availability of trusted computer systems. In support of this goal the NCSC created a metric, the DoD Trusted Computer System Evaluation Criteria (TCSEC) [2], against which computer systems could be evaluated.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.
1.2 PURPOSEThis document is written to help vendors and evaluators understand the object reuse requirement. It also provides guidance to vendors on how to design and incorporate effective object reuse mechanisms into their systems. Some examples for accomplishing object reuse are provided in this document, but they are not the only way to meet the requirement. Nor are the recommendations supplementary requirements to the TCSEC. The only measure of TCSEC compliance is the TCSEC itself.
1.3 SCOPEThis guideline discusses the object reuse requirement applicable to the trusted computing bases (TClBs) found in classes C2 through Al. Although it is directed toward object reuse, this guideline also addresses other TCSEC requirements that tend to strengthen the assurance for the correct performance of object reuse.
1.4 CONTROL OBJECTIVEThe general control objective for object reuse is specified in the TCSEC. It was originally obtained from DoD Directive 5200.28 (April `78 version) which has now been modified and reissued (March `88) but still embodies the spirit of the original requirement. It requires automated information systems (AISs) processing classified information to, "with reasonable dependability, prevent:
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).
2 OVERVIEW OF PRINCIPLESObject reuse is defined by A Guide to Understanding Data Remanence in Automated Information Systems as:
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].
2.1 THE TCSEC OBJECT REUSE REQUIREMENTThe object reuse requirement first appears at class C2 (controlled access protection) and remains unchanged through class Al (verified protection). Although the requirement remains unchanged, the assurance of proper implementation increases as the class increases.
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.
2.2 PURPOSE OF THE OBJECT REUSE REQUIREMENTAs stated in section 1.3, the object reuse requirement is primarily designed to satisfy DoD Directive 5200.28 which requires that "Classified information and sensitive unclassified information shall be safeguarded at all times while in AIS's. Safeguards shall be applied so that such information is accessed only by authorized persons . . . .,` [4, page 3] Without this requirement, storage objects could become an information transfer channel between disjoint users as the system reassigns the objects upon user request. Assurance must be provided that no data in any storage object is accessible upon allocation of that object---even if the object is reallocated to the subject having had the most recent access right to it.
2.3 APPLICABILITY OF THE OBJECT REUSE REQUIREMENTThe TCSEC object reuse requirement applies to all storage objects defined by an AIS that are protected by its TCB. The set of storage objects often referred to by a user may be (and likely are) different from the set of physical objects that the system must apply the object reuse requirement to. Whereas the user tends to focus on files or memory space, for example, the system implements these abstract or user-visible objects through the use of real objects such as disk blocks, memory pages or segments, records, bytes, and bits. When a user deletes a file, the system must translate the deallocation of the virtualized file into the deallocation of the corresponding control and data blocks that actually implement the file. A consequence of clearing the physical structures of residual data must be the clearing of the abstract object. Some common physical objects include those items listed in Table 2.
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.
2.4 SUMMARYObject reuse mechanisms ensure system resources are allocated and reassigned among authorized AIS users in a way which prevents the leak of sensitive information. Object reuse does not necessarily protect against physical attacks on the storage medium. Without specifying how to do it, the TCSEC object reuse requirement applies to classes C2 through A1, with increasing assurance of proper execution as the class increases. The requirement concerns storage objects accessible by untrusted users of an AS; it covers all TCB protected storage objects of an AIS. However, the system designer may clear internal security relevant data structures also. The system must translate the deallocation of virtualized files into the deallocaton of the corresponding control and data blocks actually implementing the files. A result of clearing the physical structures is the clearing of the abstract object. All storage objects require object reuse, but all objects are not always under TCB control. Storage objects may or may not correspond to the objects visible to users. Additionally, some storage objects may need administrative, procedural support to ensure the performance of object reuse.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 3 IMPLEMENTATION CONSIDERATIONS FOR OBJECT REUSE3.1 CONSIDERATIONS FOR PRIMARY STORAGE OBJECTSAutomated Information Systems (ASS) rely upon a collection of primary memory to support the execution of programs. Object reuse on primary storage objects is under the control of the AIS's TCB. The TCB is directly responsible for allocating the primary storage objects, placing data into the objects, and determining when to perform object reuse. The physical memory provides virtual memory for user program execution. When the physical memory is allocated to a user, the TCB must ensure that the memory page contains no residual data. This can be done by purging the memory page with an overwriting technique. For efficiency purposes the designer may wish to use a procedure that overwrites and destroys residual data with the new data being swapped in on behalf of a new subject (in lieu of overwriting with a fixed or random pattern of bits). An important part of this technique is for the system designer to demonstrate that, in all circumstances, the residual data is overwritten prior to the allocation of memory to the incoming subject. Since page frames in main memory are of fixed size and data being swapped in or out is not likely to be an exact fit, it is incumbent upon the designer to ensure all physical page frame space is overwritten (e.g., using a fixed or random pattern of zeros and/or ones to purge the memory from the end of the data being swapped in to the end of the physical page frame).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.
3.2 FIXED MEDIA METHODSIn addition to primary storage objects, many AISs rely on fixed media to contain data for temporary (e.g., buffer or inactive page frame) or long term storage (e.g., file retention). This media may be a fixed disk, the memory in a terminal, and so on. The system designer must identify all physical objects (i.e., blocks, bytes, words) that reside on this media which are used to represent the more abstract objects the user considers (i.e., files, records, programs).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.
3.3 REMOVABLE MEDIA METHODSThis section discusses some possible implementation approaches that could be the basis for an object reuse mechanism for removable (or removed) media. Removable media represents a special case because it can physically be removed from the system. This means that it no longer comes under TCB controls and thus the automated object reuse procedures must be augmented by physical and procedural controls described in the Trusted Facility Manual.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.
3.4 MANAGEMENT OF REMOVABLE MEDIAThe problem with off-line object reuse preparation is not with the method used to eliminate the residue from previous use, but the management of the reintroduction to the TCB of media that was degaussed or overwritten. From the TCB's perspective, it must know it is allocating an object (storage medium) that has been properly processed for reuse. In the case of the fixed media, the TCB itself largely has total control of the process, and the design verification process assures that the TCB only allocates from properly processed reusable objects.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.
3.5 SUMMARYAn AIS's TCB controls object reuse on storage media (primary storage, fixed media, and removable media). Demonstrate the TCB's ability to assure proper object reuse by identifying all physical objects on this media which represent abstract user objects and by examining the routines controlling initialization, allocation, and deallocation. To ensure an initially-secure state for the system, initialize the media to an appropriate condition. Physical and procedural controls augment the automated object reuse procedures of storage media (even primary memory and fixed media) removed from the system and, thus, from TCB controls.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.
ASSURANCE
|
