Filter
Top Products
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/SM
TM
, z/VM
TM
, 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.3 Approach 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