3.2. User space object Manager

A very powerful feature of the SELinux architecture is that it can be applied not only to user-space resources but also to kernel resources. Indeed, he derives from a study of microkernel, in which most resources are managed by user-space servers. Examples of user-space servers that can enforce access control over resources in Linux are X services and database services. These servers provide the abstraction resources that are available to enforce security. This section mentions two user-space servers supported by the SELinux architecture.

3.2.1 Kernel support for User space object Manager

One simple way for SELinux to support user space objects is through the kernel secure server, as shown in the following diagram:

In this way, the user space object manager and the kernel object management behavior is very similar. The Kernel Security service contains the entire security policy, and the user space object manager must consult the kernel to obtain access control decisions, the main difference is that the user space object Manager can not use the kernel AVC (Access vector cache). Each server has its own, detached AVC to store his past decision from the kernel request. For the user space server, the AVC function is included in the library Libselinux.

Another difference is that the user space object manager has no 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 manipulates cache misses and queries the kernel on behalf of the object manager.

Frankly, there are some drawbacks to this way of supporting the user's Spatial object manager. First, in order to use type enforcement policies, the object manager must define the object classes that represent their resources. For example, a database server must define object classes that contain databases, tables, schemas, entities, and so on. For kernel resources, the object class is complex and conforms to the hard-coded class defined in SELinux's LSM module header file. The relationship between class definitions in the policy plus you these kernel encodings lead to a dependency on the user space policy and coding. In particular, two user space servers must be careful not to use the same object class in the kernel. The kernel does not provide a workaround for this conflict.

The second disadvantage of this approach is that the kernel security server is the object class management strategy for those objects that are not in the kernel. This increases the storage overhead of the kernel-independent abstract body and affects the cost of kernel policy validation in the case of AVC misses.

3.2.2 Policy Server Schema

In order to solve the disadvantage of using kernel Secure server for User space Object Server and to improve the security of SELinux, an ongoing effort is to provide user space support for User space object manager. The project has two main goals and a number of second goals. The main objectives are:

• 1: Provide better support for user space object Manager by providing a user-space secure server, which makes access decisions for the user's policy part.
• 2: By building a policy Management Server to provide granular access control to the policy, the policy Management Server is a user-space object Manager whose object class represents the strategy part.

On the whole, the two servers and the policy server are related. The following figure shows the schema of the policy server.

In the policy server architecture, all operations and management of the entire system policy is controlled through the Policy Management Server (PMS). PMS is a user-space object manager, in which he creates object classes that represent policy resources and enforces a finer-grained access control strategy for those resources. This feature provides a very important security enhancement for selinux. Prior to this, access control over the policy was either a topic with or without. You can either write a policy file or not at all. With PMS, you first have the ability to allow access to the rough parts and restrict access to other. For example, the SELinux policy allows the user to manage tools to add users and to make role assignments, but cannot change the type enforcement of the types rule. Better yet, you can allow a database server to change the TE policy associated with his object class and type, but not those in the kernel. Internally, the PMS is designed to use the most recent feature of SELinux to load the Strategy module, which is described in a later section.

The second major function of the PMS is to detach the system policy to the kernel and user sections and load them into the kernel secure server and the user space Secure Server (USSS), respectively. In this way, the kernel is not aware of the rules and object classes, only the user space object manager is of great significance. The user space object Manager consults the USSS rather than the kernel. For policy update and cache affinity functionality, AVC in different User space object Manager registers with USSS (not the kernel).

In addition to the kernel's removal of responsibility for user space resources and finer-grained access to policy management, the policy server architecture has more advantages. Because PMS is a running server, we can extend his interface to allow remote network access to distributed policy management. PMS and USSS are designed to allow runtime object class registration, breaking the coding dependency of the user space object manager that exists in the kernel. The difference between the two approaches is obscured by Libselinux's backward compatibility with existing work. Ultimately, PMS and USSS are designed as separate services that run one or two of them when there is no other. For example, in a system where fine-grained policy access control is useless, usss can be used alone to support other user-space object servers.

Copyright NOTICE: Hello, reprint please leave my blog address, thank you

3.2. User space object Manager