NB CoreComponents

From SELinux Wiki
Jump to: navigation, search

Core SELinux Components

The High Level Core SELinux Components diagram shows a high level view of the core SELinux components that manage enforcement of the policy and comprises of the following:

  1. A subject that must be present to cause an action to be taken by an object (such as read a file as information only flows when a subject is involved).
  2. An Object Manager that knows the actions required of the particular resource (such as a file) and can enforce those actions (i.e. allow it to write to a file if permitted by the policy).
  3. A Security Server that makes decisions regarding the subjects rights to perform the requested action on the object, based on the security policy rules.
  4. A Security Policy that describes the rules using the SELinux policy language.
  5. An Access Vector Cache (AVC) that improves system performance by caching security server decisions.

Note that decisions by the Security Server are cached in the AVC to enhance performance of future requests, and that it is the kernel and userspace Object Managers that enforce the policy.

The High Level SELinux Architecture diagram shows a more complex view of the kernel and userspace with a number of supporting services that are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore starting from the bottom:

  • In the current implementation of SELinux the security server is embedded in the kernel with the policy being loaded from userspace via a series of functions contained in the libselinux library (see SELinux Userspace Libraries for details).

The object managers (OM) and access vector cache (AVC) can reside in:

kernel space - These object manages are for the kernel services such as files, directory, socket, IPC etc. and are provided by hooks into the SELinux sub-system via the Linux Security Module (LSM) framework (shown as LSM Hooks in the High Level SELinux Architecture diagram) that is discussed in the Linux Security Module and SELinux section. The SELinux kernel AVC service is used to cache the security servers response to the kernel based object managers thus speeding up access decisions should the same request be asked in future.
userspace - These object managers are provided with the application or service that requires support for MAC and are known as 'SELinux-aware' applications or services. Examples of these are: X-Windows, D-bus messaging (used by the Gnome desktop), PostgreSQL database, Name Service Cache Daemon (nscd), and the GNU / Linux passwd command. Generally, these OMs use the AVC services built into the SELinux library (libselinux), however they could, if required supply their own AVC or not use an AVC at all (see Implementing SELinux-aware Applications for details).
  • The SELinux security policy (right hand side in the High Level SELinux Architecture diagram) and its supporting configuration files are contained in the /etc/selinux directory. This directory contains the main SELinux configuration file (/etc/selinux/config) that has the name of the policy to be loaded (via the SELINUXTYPE entry) and the initial enforcement mode[1] of the policy at load time (via the SELINUX entry). The /etc/selinux/<SELINUXTYPE> directories contain policies that can be activated along with their configuration files (e.g. 'SELINUXTYPE=targeted' will have its policy and associated configuration files located at /etc/selinux/targeted). All known policy configuration files are shown in the Policy Configuration Files section.
  • SELinux supports a 'modular policy', this means that a policy does not have to be one large source policy but can be built from modules. A modular policy consists of a base policy that contains the mandatory information (such as object classes, permissions etc.), and zero or more policy modules where generally each supports a particular application or service. These modules are compiled, linked, and held in a 'policy store' where they can be built into a binary format that is then loaded into the security server (in the High Level SELinux Architecture diagram, the binary policy is located at /etc/selinux/targeted/policy/policy.29). The types of policy and their construction are covered in the Types of SELinux Policy section.
  • To be able to build the policy in the first place, policy source is required (top left hand side of the High Level SELinux Architecture diagram). This can be supplied in three basic ways:
    • as source code written using the Kernel Policy Language. This is how the simple policies have been written to support the examples in this Notebook, however it is not recommended for large policy developments such as the Reference Policy, although the smaller SE for Android policy is written this way with some m4 macro support.
    • using the Reference Policy that has high level macros to define policy rules. This is the standard way policies are now built for SELinux distributions such as Red Hat and Debian and is discussed in the Reference Policy section. Note that SE for Android also uses high level macros to define policy rules but the overall policy is much less complex.
    • using CIL (Common Intermediate Language). An overview can be found at https://github.com/SELinuxProject/cil/wiki and CIL Policy Language.
  • To be able to compile and link the policy source then load it into the security server requires a number of tools (top of High Level SELinux Architecture diagram).
  • To enable system administrators to manage policy, the SELinux environment and label file systems, tools and modified GNU / Linux commands are used. These are mentioned throughout the Notebook as needed. Note that there are many other applications to manage policy, however this Notebook only concentrates on the core services.
  • To ensure security events are logged, GNU / Linux has an audit service that captures policy violations. The Auditing SELinux Events section describes the format of these security events.

The Linux Security Module and SELinux section goes into greater detail of the LSM / SELinux modules with a walk-through of a fork and exec process.


Previous
Home
Next



  1. When SELinux is enabled, the policy can be running in 'permissive mode' (SELINUX=permissive), where all accesses are allowed. The policy can also be run in 'enforcing mode' (SELINUX=enforcing), where any access that is not defined in the policy is denied and an entry placed in the audit log. SELinux can also be disabled (at boot time only) by setting SELINUX=disabled. There is also support for the permissive statement that allows a domain to run in permissive mode while the others are still confined (instead of the all or nothing set by SELINUX=).