PD-0050: How Should Libraries Be Handled Relative to the ADV_FSP.1 work units of the CEM?

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

How should libraries, both static and dynamic, be treated relative to the requirements to document the TSF interfaces? For example, consider a Unix-like system that uses authentication modules. Because those modules are implemented through a library, is it required that the library be described in the functional specification? Additionally, are there any CC or CEM requirements relative to TOE configuration as a consequence of a particular authentication configuration and/or module stacking (e.g., ADO_IGS.1 implications)? For example, suppose that a user installed an alternate I&A module which resulted in a bypass of I&A security functions?

As a related library issue, there is the question of TOE/TOE environment regarding networking. Consider an operating system that does not provide network-based system calls but instead provides networking support through a library interface. It is apparent that there are kernel interfaces described within the functions that compose this library. It is not clear how the CC/CEM requirements relate to this case, in particular the requirements to document the interfaces.

Resolution

1. Libraries represent collections of reusable code. As such, they need to be treated in the manner appropriate for that code. In particular, library routines that are used within the TSF would be identified and described in HLD and/or LLD documentation, consistent with the targetted EAL level of the TOE.

2. As for the configuration issue, the administrative guidance needs to describe how to administer and configure the TOE in order to maintain security; this is covered in AGD_ADM.1.5.C. If evaluated elements of the TOE are altered, removed, or replaced, then the product is not functioning in its evaluated configuration and is, in effect, a different product from the one that was evaluated. Thus, the evaluation results cannot be applied to the altered product. If, however, the question is about unauthorized users making such alterations, then this must be judged as a flaw or vulnerabilty.

3. For the case of the network interfaces, it is acceptable for such a layer to be documented as the interface. However, the design documentation must also show how this layer interfaces with the actual kernel interface.

Support

1. Libraries are only code; there is, fundamentally, nothing special about such code. The issues revolve about how the code is used in the system. Code that forms part of the TSF is either internal to the TSF or it forms part of the exported interface. If the latter, then the interfaces must be described in the FSP documentation. In either case, the code must be shown to be protected from tampering, and must satisfy all other requirements of TSF internals.

2. Regarding the configuration question, there are two cases:

   1. An authorized user/administrator modifies the TOE. In this case, the TOE is no longer running in the evaluated configuration and thus no claims can be made about it; it is no longer the evaluated product.

   2. An unauthorized user modifies the TOE. This is a flaw or the result of a vulnerability. Depending upon the seriousness of the flaw (perhaps a fundamental design problem), the ease with which it can be exploited, and the targetted EAL level, the TOE could be found to be non-compliant with the requirements and thus be found to fail the evaluation.

3. The case described for the network socket calls is just a more complex form of an API library. As noted, it is acceptable to show this layer as the user interface, but the translation between this layer and the TSF must also be described. In most Unix systems a simpler form of this case exists; there is a library that translates the kernel API to a single machine trap instruction.

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: 0079