IBM 10 SP1 EAL4 Manual Do Utilizador
•
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.
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:
privileges includes:
•
The base SLES kernel. This constitutes a large portion of software that performs memory
management file I/O and process management.
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 statically-linked kernel function.
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 statically-linked kernel function.
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. User-mode processes run with hardware
privileges when they invoke a system call. The execution of the system call switches the mode from user to
kernel mode, and continues operation at a designated address within the kernel where the code of the system
call is located.
processes such as shells, networking client software, and editors. User-mode processes run with hardware
privileges when they invoke a system call. The execution of the system call switches the mode from user to
kernel mode, and continues operation at a designated address within the kernel where the code of the system
call is located.
4.1.2 Software 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:
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
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 multi-step process, described in Section 5.8, to determine if access should be
allowed.
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 multi-step process, described in Section 5.8, to determine if access should be
allowed.
20