3.1. kernel architecture, 3.1 kernel architecture

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

The SELinux kernel architecture reflects the Flask architecture, which is designed for the microkernel environment. The Flask architecture has three main parts, as shown in the following figure: security server, object manager, and access Vector cache.

The Design of Flask makes a big difference between security policy decisions and enforcement functions. Policy decision-making is the work of the security server. The security server reflects the root of The SELinux microkernel, and the policy determines that the role is encapsulated in a user space server. In Linux, the security server of the kernel object is placed in The SELinux LSM module. The policy used for security server is to sneak into the rule set and load it through the policy management interface. These rules can be different between systems, which enables SELinux to meet the security goals of different organizations. This architecture is designed so that the security server can be completely replaced by logic, which can implement a complete new access control policy without changing other architectures. Actually,
The new security server is not required because the identifier enforcement policy provides sufficient flexibility for almost any access control security policy.

The object manager is used to force the Security Server decisions on the resources they manage. For the kernel, You can regard the object manager as the kernel subsystem, which can create and manage the objects at the kernel layer. Examples of Kernel Object Manager include file system, process management, and IPC. In the LSM architecture, the object manager is represented by LSM hooks, which are scattered throughout the kernel subsystem and decide to call The SELinux LSM module for access. LSM hooks force decisions by allowing or rejecting access to kernel resources.

The third component of the SELinux architecture 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.

Copyright Disclaimer: Hello, please leave the address of your blog for reprinting. Thank you.