PD-0049: Identification and Description of TSF Interfaces

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

The various statements in the CEM work units and the CC Part2 requirements relating to the ADV_FSP requirements are confusing and seemingly contradictory.

The CEM work units ADV_FSP.1-3 and ADV_FSP.1-4 require the evaluator to examine the external interfaces to the TSF. Para. 997 of the CEM states, "Because each external interface is a potential TSF interface, the functional specification must contain a description of each interface in sufficient detail so that an evaluator can determine whether the interface is security relevant."

The above statement appears to be contradicted by the following paragraph (i.e., para 998) which states, "Any program external to the kernel that executes without privilege is incapable of affecting the TSP ... and may, therefore, be excluded from the functional specification."

Further complication is introduced because it is possible that some TOE security functions occur in "user space" (i.e., the unprivileged domain), such as I&A.

Resolution

Paragraph 997 of the CEM is clear; when the TOE supports user processes then all external interfaces (i.e., user-visible interfaces) to the TSF must be identified and described.

Support

Every external interface to the TSF must be security-preserving. Thus, it must be demonstrable that even seemingly innocuous calls (e.g., time-of-day) not only function as specified but also provide neither capability for violating or bypassing the TSP, nor information that reveals internal details of the TSF. Unless all the interfaces are identified and described, the evaluator has no way of assessing the security relevance of each interface, assessing the level of effort that should be expended in reviewing the interface implementation, nor assessing the adequacy and completeness of testing.

The referenced CEM paragraphs deal specifically with the case for which a potential for bypassing the TSF exists. In essence, this is the case for TOEs that also support untrusted user processes (e.g., DBMS, general-purpose O/S). Paragraph 998 of the CEM is an example, a condition of which is that the kernel handles all operating system calls. As such, the cited sentence justifies the exclusion of non-privileged programs from the TSF. A process that executes in the user domain (or, "user space") which enforces part of the TSP, such as I&A, would require some sort of privilege or otherwise be trusted relative to the TSP. Therefore, it is part of the TSF. There is no contradiction.

Modification History:

2004-08-12

Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

References:

• CC v2.1

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0181