IBM 10 SP1 EAL4 4 Software architecture

4 Software architecture

This chapter summarizes the software structure and design of the SLES system and provides references to

detailed design documentation.

The following subsections describe the TOE Security Functions (TSF) software and the TSF databases for the

SLES system. The descriptions are organized according to the structure of the system and describe the SLES

kernel that controls access to shared resources from trusted (administrator) and untrusted (user) processes.

This chapter provides a detailed look at the architectural pieces, or subsystems, that make up the kernel and

the non-kernel TSF. This chapter also summarizes the databases that are used by the TSF.

The Functional Description chapter that follows this chapter describes the functions performed by the SLES

logical subsystems. These logical subsystems generally correspond to the architectural subsystems described

in this chapter. The two topics were separated into different chapters in order to emphasize that the material

in the Functional Descriptions chapter describes how the system performs certain key security-relevant

functions. The material in this chapter provides the foundation information for the descriptions in the

Functional Description chapter.

This section describes the terms hardware privilege and software privilege as they relate to the SLES

operating system. These two types of privileges are critical for the SLES system to provide TSF self-

protection. This section does not enumerate the privileged and unprivileged programs. Rather, the TSF

Software Structure identifies the privileged software as part of the description of the structure of the system.

The eServer systems are powered by different types of processors. Each of these processors provides a notion

of user mode execution and supervisor, or kernel, mode execution. The following briefly describes how these

user- and kernel-execution modes are provided by the System x, System p, System z, and eServer 326

systems.

This section describes the concept of privilege levels by using Intel-based processors as an example. The

concept of privilege is implemented by assigning a value of 0 to 3 to key objects recognized by the processor.

This value is called the privilege level. The following processor-recognized objects contain privilege levels:

•Descriptors contain a field called the descriptor privilege level (DPL).

•Selectors contain a field called the requestor’s privilege level (RPL). The RPL is intended to

represent the privilege level of the procedure that originates the selector.

•An internal processor register records the current privilege level (CPL). Normally the CPL is equal

to the DPL of the segment the processor is currently executing. The CPL changes as control is

transferred to segments with differing DPLs.

Figure 4-1 shows how these levels of privilege can be interpreted as layers of protection. The center is for the

segments containing the most critical software, usually the kernel of the operating system. Outer layers are for

the segments of less critical software.