3.2. user space object manager, space object manager
A very powerful feature of SELinux architecture is that it can be applied not only to user space resources but also to kernel resources. Indeed, he came from the research on the micro-kernel. In the micro-kernel, most resources are managed by the user space server. In Linux, examples of user space servers that can enforce resource access control include X services and database services. These servers provide abstract resources that can be provided by mandatory security. This section mentions two types of user space servers supported by The SELinux architecture.
3.2.1 Kernel support for the user space object manager
One simple way SELinux supports user space objects is to directly use the kernel security server, as shown in the following figure:
In this way, the user space object manager and the kernel object management behavior are very similar. The kernel security service includes the entire security policy, and the user space object manager must consult the kernel to obtain access control decisions, the main difference between the two is that the user space object manager cannot use the kernel's AVC (access vector cache ). Each server must have its own isolated AVC to store its previous decisions from kernel requests. For a user space server, the AVC function is included in the libselinux library.
Another difference is that the user space object manager does not have LSM hooks, and LSM hooks are the concept of kernel space. However, the AVC of the Object Manager in libselinux has a kernel interface. AVC indicates that the cache is not hit and represents the query kernel of the Object Manager.
To put it bluntly, this method of supporting the user space object manager has some disadvantages. First, to use a type-based policy, the object manager must define the object class that can represent their resources. For example, a database server must define object classes that contain databases, tables, modes, and entities. For kernel resources, the object class is complex and consistent with the hard encoding class defined in the header file of the LSM module of SELinux. Adding the kernel encoding in the class-defined relationship in the policy leads to dependency between the user space policy and the encoding. In particular, the two user space servers must be careful not to use the same object class in the kernel. The kernel does not provide a solution to this conflict.
The second disadvantage of this approach is that the kernel security server manages policies for the object classes that are not in the kernel's object manager. This increases the storage overhead of kernel-independent abstract bodies and affects the overhead of kernel policy verification when AVC is not hit.
3.2.2 Policy Server Architecture
To solve the disadvantages of using the kernel security server on the object server of the user space and improve the security of SELinux, an ongoing effort is to provide user space support for the object manager of the user space. This project has two main objectives and some second goals. The main objectives are:
- 1: provides a user space security server to provide better support for the user space object manager. The security server makes access decisions for the user's policy part.
- 2: A Policy Management Server is built to provide fine-grained access control for the policy. The policy management server is a user space object manager and its object class represents the policy part.
On the whole, these two servers are related to policy servers. The figure below shows the architecture of the Policy server.
In the policy server architecture, all operations and management of the overall system policy are controlled by the Policy Management Server (PMS. PMS is a user space object manager. In PMS, it creates object classes that represent policy resources and enforces a more fine-grained access control policy for these resources. This feature provides a very important security enhancement for SELinux. Previously, policy access control was an issue that either existed or was completely unavailable. You can either write a policy file or not at all. With PMS, you must first allow access to the rough section and restrict access to others. For example, The SELinux policy allows the user management tool to add users and assign roles. However, the type-based mandatory type rule cannot be changed. Better yet, you can allow a database server to change the TE policies related to its object classes and types, but not those in the kernel. Internally, PMS are designed to use the latest feature of SELinux to load policy modules, which will be described in later sections.
The second major function of PMS is to separate system policies from the kernel and the user, and load them to the kernel security server and the user space security server (USSS) respectively ). In this way, the kernel does not understand the rules and object classes, but is of great significance to the user space object manager. The user space object manager consulted USSS instead of the kernel. For policy update and cache-related features, AVC in different user space object managers registers with USSS (not the kernel ).
In addition to the removal of the responsibility of the kernel for user space resources and more fine-grained access to policy management, the policy server architecture has more advantages. Because PMS is a running server, we can extend its interfaces to allow remote network access to distributed policy management. PMS and USSS are designed to allow object class registration during runtime, breaking the coding dependency of the user space object manager in the kernel. Libselinux provides backward compatibility for the current work. In the end, PMS and USSS are designed as separate services. When there is no other service, either or both of them will be used. For example, in a system where fine-grained access control is useless, USSS can be used independently to support other user space object servers.
Copyright Disclaimer: Hello, please leave the address of your blog for reprinting. Thank you.