Section 3.2. Userspace Object Managers

3.2. Userspace Object Managers

One of the powerful features of the SELinux architecture is that it can be applied to userspace resources and to kernel resources. Indeed, its origins were in microkernel research where most resource management was performed by userspace servers. Examples of userspace servers in Linux that can be enhanced to enforce access control over their resources include the X server and database services. Each of these servers provides abstract resources (windows, tables, and so on) over which mandatory security could be provided. This section examines two ways that the SELinux architecture supports userspace servers.

3.2.1. Kernel Support for Userspace Object Managers

A simple way SELinux supports userspace objects is directly via the kernel security server, as depicted in Figure 3-3.

Figure 3-3. Userspace object managers using kernel security server

In this method, the userspace object manager behaves much like the kernel object managers. The kernel security server contains the entire security policy, and the userspace object manager must query the kernel for access control decisions. The primary difference is that userspace object managers cannot use the kernel AVC. Each server must have its own, separate AVC that stores the past decisions it has requested from the kernel. The AVC functionality for userspace servers is contained in the library libselinux.

Another difference is that userspace object managers do not have LSM hooks, which are a kernel-space concept. Instead, the object manager has internal interfaces with its AVC inside libselinux. The AVC handles cache misses and queries the kernel on behalf of the object manager.

Although straightforward, this method for supporting userspace object managers has a number of weaknesses. First, to use type enforcement, object managers must define object classes that represent their resources. For example, a database server might define object classes that include database, table, schema, entry, and so on. For kernel resources, object classes are fixed and correspond to hard-coded class offsets defined in SELinux LSM module header files. The relationship of class definitions in the policy and with those in the kernel code results in an unfortunate dependency between the userspace policy and the code. Specifically, two userspace servers must be careful not to both use the same object class offset in the kernel. The kernel provides no way to manage this possible conflict.

The second weakness with this approach is that kernel security server is managing policy for object classes for object managers that are not in the kernel. This increases storage cost within the kernel for abstraction not related to the kernel and can negatively impact the cost of kernel policy validation for AVC misses.

3.2.2. Policy Server Architecture

To address the weaknesses of using the kernel security server for userspace object managers and to enhance the security capabilities of SELinux, an effort is ongoing to build userspace support for userspace object managers. This project has two primary goals and a number of secondary goals. The primary goals are as follows:

• Provide better support for user-space object managers by providing a user-space security server that makes access decisions for the user portion of the policy

• Provide fine-grained access control for the policy itself by building a policy management server that is a userspace object manager whose object classes represent portions of the policy

Collectively, these two servers are referred to as the policy server. Figure 3-4 depicts the architecture of the policy server.

Figure 3-4. SELinux policy server architecture

In the policy server architecture, all manipulation and management of the overall system policy is controlled through the policy management server (PMS). The PMS is itself a userspace object manager in that it creates object classes representing policy resources and enforces a fine-grained access control policy over those resources. This feature alone provides significant security enhancement for SELinux. Previously, access control to the policy was an all-or-nothing proposition; you either could write the policy file or not. With the PMS, you can now allow access to portions of the policy and limit access to others. For example, the SELinux policy can allow user management tools to add users and make role assignments, but not change type enforcement allow rules. Better yet, you can authorize a database server to change type enforcement (TE) rules relating to its object classes and types, but not those of the kernel. Internally, the PMS is designed to use another recent new feature of SELinux, loadable policy modules, which we describe later in this chapter.

The second major function of the PMS is to split the system policy into kernel and user portions and load them respectively into the kernel security server and userspace security server (USSS). In this way, the kernel is not made aware of rules and object classes of concern only to userspace object managers. Userspace object managers query the USSS and not the kernel. AVCs in various userspace object managers register with the USSS (and not the kernel) for policy update and cache coherency functions.

The policy server architecture has a number of strengths in addition to the removal of the kernel's responsibility for userspace resources and the fine-grained access for policy management. Because the PMS is a running server, we can extend its interface to allow remote network access for distributed policy management. The PMS and USSS are designed to allow for runtime registration of object classes, breaking the code dependency for userspace object managers that exists in the kernel. The difference between the two approaches is masked by libselinux providing backward compatibility with existing work. Finally, the PMS and USSS are designed as separate services to allow for one or both to be used without the other. For example, in a system where fine-grained policy access control is unnecessary, the USSS could be used alone to support other userspace object servers.

At the time of this writing, the policy server work is under development and not fully integrated into any distributions. You can check the status of this work at http://sepolicy-server.sourceforge.net.