IBM 10 SP1 EAL4 manual Approach to TSF identification

The local TSF interfaces provided by an individual host computer include:

•Files that are part of the TSF database that define the configuration parameters used by the security functions.

•System calls made by trusted and untrusted programs to the privileged kernel-mode software. As described separately in this document, system calls are exported by the base SLES kernel and by kernel modules.

•Interfaces to trusted processes and trusted programs

•Interfaces to the SLES kernel through the /proc and the /sys pseudo file systems

External TSF interfaces provided by pairs of host computer include SSH v2 and SSL v3. For more detailed information about these interfaces, refer to:

•SSH v2 Proposed Standard RFC 4819 Secure Shell Public Key Subsystem http://www.ietf.org/rfc/rfc4819.txt

•SSLv3 Draft http://wp.netscape.com/eng/ssl3/draft302.txt

•RFC 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) http://www.ietf.org/rfc/rfc3268.txt

The following are interfaces that are not viewed as TSF interfaces:

•Interfaces between non-TSF processes and the underlying hardware. Typically, user processes do not interface directly with the hardware; exceptions are processor and graphics hardware. User processes interact with the processor by executing CPU instructions, reading and modifying CPU registers, and modifying the contents of physical memory assigned to the process. User processes interact with graphics hardware by modifying the contents of registers and memory on the graphics adapter. Unprivileged processor instructions are externally visible interfaces. However, the unprivileged processor instructions do not implement any security functionality, and the processor restricts these instructions to the bounds defined by the processor. Therefore, this interface is not considered as part of the TSF.

•Interfaces between different parts of the TSF that are invisible to normal users (for example, between subroutines within the kernel) are not considered to be TSF interfaces. This is because the interface is internal to the trusted part of the TOE and cannot be invoked outside of those parts. Those interfaces are therefore not part of the functional specification, but are explained in this HLD.

•The firmware (PR/SMTM, z/VMTM, P5-LPAR), while part of the TOE, are not considered as providing TSF interfaces because they do not allow direct unprivileged operations to them.

•System z processor exceptions reflected to the firmware, including z/VM, PR/SM, and LPAR, are not considered to be TSF interfaces. They are not relevant to security because they provide access to the z/VM kernel, which does not implement any security functionality.

•The System z z/VM DIAGNOSE code interface is not considered a TSF interface because it is not accessible by unprivileged processes in the problem state, and does not provide any security functionality.

TSF interfaces include any interface that is possible between untrusted software and the TSF.

2.3Approach to TSF identification

This section summarizes the approach to identification of the TSF.

As stated in Section 2.2.6, while the hardware and firmware (z/VM, PR/SM, LPAR) are part of the TOE, they are not considered as providing TSF interfaces. The SLES operating system, on the other hand, does provide TSF interfaces.

9