3. 1. kernel architecture

3. 1. kernel architecture

SELinux provides mandatory access control for all kernel resources. In his current format, SELinux is merged into the kernel through the LSM Framework.

3.1.1. LSM Framework

The idea behind the LSM Framework is to allow the security module to be inserted into the kernel to better control Linux's default identity-based access control security mode. In the kernel system calling logic, LSM provides a series of hooks ). These hooks are usually placed after the standard Linux access check, before the kernel calls access to real resources. The following figure illustrates the basic LSM Framework.

SELinux is loaded into the kernel as a LSM module and used as an additional access verification before access attempts are allowed.

One branch of the LSM Framework is that SELinux will be asked only after the standard Linux access check is passed. In fact, there is no negative impact on the access control policy, because the access control of SELinux is stricter than that of the standard Linux DAC and does not cover the DAC decision. However, the LSM Framework can affect statistics collected by SELinux. For example, if you want to use the audit data of SELinux to observe all access denied, you must be aware that SELinux will not be asked in most cases, therefore, if the rejection is the result of the standard Linux security mode, it will not be counted by SELinux.

The LSM Framework is comprehensive and the hooks are scattered throughout the kernel. Each LSM hook converts one or more object classes to one or more access permissions. Understanding object access in SELinux is related to understanding the majority of LSM hooks. In chapter 4, "object class and permission" discusses the object class and permission in details.

3.1.2. SELinux LSM Module <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Fill + 31qOs1f3I58/Cw + a1xM28svvK9rXExMfR + aO6sLLIq7f + fill/fill = "here write picture description" src = "http://www.bkjia.com/uploads/allimg/150718/0404514B3-1.png" title = "fill V fill solder Qian? Fu? Why ??! Too many? Example-# example ?? ?...? The http://www.bkjia.com/kf/all/zujian/ "target =" _ blank "class =" keylink "> component is the access Vector cache (AVC ). The AVC cache is used for subsequent access checks by the security server to provide effective performance improvement for access verification. AVC also provides SELinux interfaces for LSM hooks and Kernel Object managers.

When a policy is loaded, AVC becomes invalid. Therefore, cache continuity must be maintained. However, when the policy changes, SELinux does not completely implement access revocation. Compared with standard linux, This is not bad because access revocation is not implemented in standard linux. In standard linux, if you have a file descriptor, you can use it no matter how the file access mode changes. In SELinux, objects like files are verified for any access attempts made to them (for example, every policy-related read system call is checked, and not just open the call), such access revocation works well. Only one file descriptor does not mean the access to the file is agreed. For some resources, such as memory ing files and connection-oriented sockets, access is verified only when the resource is accessed for the first time. In these cases, the existing access will not be canceled. We expect that more in-depth research will be conducted in the future to improve access revocation in SELinux.