•When the processor is in kernel mode, the program has hardware privilege because it can execute certain privileged instructions that are not available in user mode.
Thus, any code that runs in kernel mode executes with hardware privileges. Software that runs with hardware privileges includes:
•The base SLES kernel. This constitutes a large portion of software that performs memory management file I/O and process management.
•Separately loaded kernel modules, such as ext3 device driver modules. A module is an object file whose code can be linked to, and unlinked from, the kernel at runtime. The module code is executed in kernel mode on behalf of the current process, like any other
All other software on the system normally runs in user mode, without hardware privileges, including user processes such as shells, networking client software, and editors.
4.1.2Software privilege
Software privilege is implemented in the SLES software and is based on the user ID of the process. Processes with user ID of 0 are allowed to bypass the system’s access control policies. Examples of programs running with software privilege are:
Programs that are run by the system, such as the cron and at daemon.
Programs that are run by trusted administrators to perform system administration.
Programs that run with privileged identity by executing setuid programs.
The SLES kernel also has a framework for providing software privilege through capabilities. These capabilities, which are based on the POSIX.1e draft, allow breakup of the kernel software privilege associated with user ID zero into a set of discrete privileges based on the operation being attempted. For example, if a process is trying to create a device special file by invoking the mknod() system call, instead of checking to ensure that the user ID is zero, the kernel checks to ensure that the process is “capable” of creating device special files. In the absence of special kernel modules that define and use capabilities, as is the case with the TOE, capability checks revert back to granting kernel software privilege based on the user ID of the process.
All software that runs with hardware privileges or software privileges and that implements security enforcing functions is part of the TSF. All other programs are either unprivileged software that run with the identity of the user that invoked the program, or software that executes with privileges but does not implement any security functions. In a properly administered system, unprivileged software is subject to the system’s security policies and does not have any means of bypassing the enforcement mechanisms. This unprivileged software need not be trusted in any way and is thus referred to as untrusted software. Trusted processes that do not implement any security function need to be protected from unauthorized tampering using the security functions of the SLES. They need to be trusted to not perform any function that violates the security policy of the SLES.
SLES implements an access control model that enforces Discretionary Access Control and optional additional access control checks implemented in a kernel module known as an Linux Security Module (LSM), such as AppArmor. Discretionary Access Control (DAC) is applied first, and the optional additional checks are applied if and only if the DAC check grants access. AppArmor, if loaded, can only further restrict access, never grant additional access. If access is granted by DAC policy and the AppArmor LSM is loaded, the AppArmor LSM goes through a
20
