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.

4.1Hardware and software privilege

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.

4.1.1Hardware privilege

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.

4.1.1.1Privilege level

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-1shows 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.

18

Page 30
Image 30
IBM 10 SP1 EAL4 manual Hardware and software privilege, Hardware privilege, Privilege level