此内容没有您所选择的语言版本。
49.7.3. The Role of Policy in the Boot Process
SELinux plays an important role during the early stages of system start-up. Because all processes must be labeled with their correct domain,
init
performs some essential operations early in the boot process to maintain synchronization between labeling and policy enforcement.
- After the kernel has been loaded during the boot process, the initial process is assigned the predefined initial SELinux ID (initial SID) kernel. Initial SIDs are used for bootstrapping before the policy is loaded.
/sbin/init
mounts/proc/
, and then searches for theselinuxfs
file system type. If it is present, that means SELinux is enabled in the kernel.- If
init
does not find SELinux in the kernel, or if it is disabled via theselinux=0
boot parameter, or if/etc/selinux/config
specifies thatSELINUX=disabled
, the boot process proceeds with a non-SELinux system.At the same time,init
sets the enforcing status if it is different from the setting in/etc/selinux/config
. This happens when a parameter is passed during the boot process, such asenforcing=0
orenforcing=1
. The kernel does not enforce any policy until the initial policy is loaded. - If SELinux is present,
/selinux/
is mounted. init
checks/selinux/policyvers
for the supported policy version. The version number in/selinux/policyvers
is the latest policy version your kernel supports.init
inspects/etc/selinux/config
to determine which policy is active, such as the targeted policy, and loads the associated file at$SELINUX_POLICY/policy.<version>
.If the binary policy is not the version supported by the kernel,init
attempts to load the policy file if it is a previous version. This provides backward compatibility with older policy versions.If the local settings in/etc/selinux/targeted/booleans
are different from those compiled in the policy,init
modifies the policy in memory based on the local settings prior to loading the policy into the kernel.- By this stage of the process, the policy is fully loaded into the kernel. The initial SIDs are then mapped to security contexts in the policy. In the case of the targeted policy, the new domain is user_u:system_r:unconfined_t. The kernel can now begin to retrieve security contexts dynamically from the in-kernel security server.
init
then re-executes itself so that it can transition to a different domain, if the policy defines it. For the targeted policy, there is no transition defined andinit
remains in theunconfined_t
domain.- At this point,
init
continues with its normal boot process.
The reason that
init
re-executes itself is to accommodate stricter SELinux policy controls. The objective of re-execution is to transition to a new domain with its own granular rules. The only way that a process can enter a domain is during execution, which means that such processes are the only entry points
into the domains.
For example, if the policy has a specific domain for
init
, such as init_t
, a method is required to change from the initial SID, such as kernel, to the correct runtime domain for init
. Because this transition may need to occur, init
is coded to re-execute itself after loading the policy.
This
init
transition occurs if the domain_auto_trans(kernel_t, init_exec_t, <target_domain_t>)
rule is present in the policy. This rule states that an automatic transition occurs on anything executing in the kernel_t
domain that executes a file of type init_exec_t. When this execution occurs, the new process is assigned the domain <target_domain_t>
, using an actual target domain such as init_t
.