This family addresses the need to ensure that deleted information is no longer accessible, and that newly-created objects do not contain information from previously used objects within the TOE. This family does not address objects stored off-line.
User notes
This family requires protection for information that has been logically deleted or released (not available to the user but still within the system and may be recoverable). In particular, this includes information that is contained in an object, as part of the TSF reusable resources, where destruction of the object does not necessarily equate to destruction of the resource or any contents of the resource.
It also applies to resources that are serially reused by different subjects within the system. For example, most operating systems typically rely upon hardware registers (resources) to support processes within the system. As processes are swapped from a "run" state to a "sleep" state (and vice versa), these registers are serially reused by different subjects. While this "swapping" action may not be considered an allocation or deallocation of a resource, FDP_RIP could apply to such events and resources.
FDP_RIP typically controls access to information that is not part of any currently defined or accessible object; however, in certain cases this may not be true. For example, object "A" is a file and object "B" is the disk upon which that file resides. If object "A" is deleted, the information from object "A" is under the control of FDP_RIP even though it is still part of object "B".
It is important to note that FDP_RIP applies only to on-line objects and not off-line objects such as those backed-up on tapes. For example, if a file is deleted in the TOE, FDP_RIP can be instantiated to require that no residual information exists upon deallocation; however, the TSF cannot extend this enforcement to that same file that exists on the off-line back-up. Therefore that same file is still available. If this is a concern, then the PP/ST author should make sure that the proper environmental objectives are in place to support administrative guidance to address off-line objects.
FDP_RIP and FDP_ROL can conflict when FDP_RIP is instantiated to require that residual information be cleared at the time the application releases the object to the TSF (i.e. upon deallocation). Therefore, the FDP_RIP selection of "deallocation" should not be used with FDP_ROL since there would be no information to roll back. The other selection, "unavailability upon allocation", may be used with FDP_ROL, but there is the risk that the resource which held the information has been allocated to a new object before the roll back took place. If that were to occur, then the roll back would not be possible.
There are no audit requirements in FDP_RIP because this is not a user-invokable function. Auditing of allocated or deallocated resources would be auditable as part of the access control SFP or the information flow control SFP operations.
This family should apply to the objects specified in the access control SFP(s) or the information flow control SFP(s) as specified by the PP/ST author.