NB Overview

From SELinux Wiki
Revision as of 13:46, 6 September 2012 by RichardHaines (Talk | contribs)

Jump to: navigation, search

SELinux Overview


SELinux is the primary Mandatory Access Control (MAC) mechanism built into a number of GNU / Linux distributions. SELinux originally started as the Flux Advanced Security Kernel (FLASK) development by the Utah university Flux team and the US Department of Defence. The development was enhanced by the NSA and released as open source software. The history of SELinux can be found at the Flux and NSA websites.

Each of the sections that follow will describe a component of SELinux, and hopefully they are is some form of logical order.

Note: When SELinux is installed, there are three well defined directory locations referenced. Two of these will change with the old and new locations as follows:

Old Location
New Location
The SELinux filesystem that interfaces with the kernel based security server. /selinux /sys/fs/selinux
The SELinux configuration directory that holds the sub-system configuration files and policies. /etc/selinux No change
The SELinux policy store that holds policy modules and configuration details /etc/selinux /var/lib/selinux

Is SELinux useful

There are many views on the usefulness of SELinux on Linux based systems, this section gives a brief view of what SELinux is good at and what it is not (because its not designed to do it).

SELinux is not just for military or high security systems where Multi-Level Security (MLS) is required (for functionality such as 'no read up' and 'no write down'), as using the 'type enforcement' (TE) functionality applications can be confined (or contained) within domains and limited to the mimimum privileges required to do their job, so in a 'nutshell':

  1. If SELinux is enabled, the policy defines what access to resources and operations on them (e.g. read, write) are allowed (i.e. SELinux stops all access unless allowed by policy). This is why SELinux is called a 'mandatory access control' (MAC) system.
  2. The policy design, implementation and testing against a defined security policy or requirements is important, otherwise there could be 'a false sense of security'.
  3. SELinux can confine an application within its own 'domain' and allow it to have the minimum priviledges required to do its job. Should the application require access to networks or other applications (or their data), then (as part of the security policy design), this access would need to be granted (so at least it is known what interactions are allowed and what are not - a good security goal).
  4. Should an application 'do something' it is not allowed by policy (intentional or otherwise), then SELinux would stop these actions.
  5. Should an application 'do something' it is allowed by policy, then SELinux may contain any damage that maybe done intentional or otherwise. For example if an application is allowed to delete all of its data files or database entries, and the bug, virus or malicious user gains these priviledges then it would be able to do the same, however the good news is that if the policy 'confined' the application and data, all your other data should still be there.
  6. User login sessions can be confined to their own domains. This allows clients they run to be given only the priviledges they need (e.g. admin users, sales staff users, HR staff users etc.). This again will confine/limit any damage or leakage of data.
  7. Some applications (X-Windows for example) are difficult to confine as they are generally designed to have total access to all resources. SELinux can generally overcome these issues by providing sandboxing services.
  8. SELinux will not stop memory leaks or buffer over-runs (because its not designed to do this), however it may contain the damage that maybe done.
  9. SELinux will not stop all viruses/malware getting into the system (as there are many ways they could be introduced (including by legitimate users), however it should limit the damage or leaks they cause.
  10. SELinux will not stop kernel vulnerabilities, however it may limit their effects.
  11. It is very easy to add new rules to an SELinux policy using tools such as audit2allow(1) if a user has the relevant permissions, however be aware that this may start opening holes, so check what rules are really required.
  12. Finally, SELinux cannot stop anything allowed by the security policy, so good design is important.

The following maybe useful in providing a practial view of SELinux:

However with careful design and known security goals the SELinux ' Apache / SELinux Plus' services could be used to build a more secure web service (also see http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus).

  • SELinux services have been added to Andriod, producing SEAndroid. The presentation "The Case for Security Enhanced (SE)Android" gives use-cases and types of Android exploits that SELinux could have overcome. The presentation is available at:


Core SELinux Components

The High Level Core SELinux Components diagram shows a high level view of the SELinux core components that manage enforcement of the policy and comprise 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.

The High Level SELinux Architecture diagram shows a more complex view of kernel and userspace with a number of supporting services which are used to manage the SELinux environment. This diagram will be referenced a number of times to explain areas of SELinux, therefore using the diagram as the reference and 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 diagram) that is discussed in the Linux Security Module(LSM) 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 of the diagram) and its supporting configuration files are contained in the /etc/selinux directory. This directory contains the main SELinux configuration file 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 configuration files for are shown in the SELinux 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 diagram the binary policy is located at /etc/selinux/targeted/policy/policy.26). 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 diagram). This can be supplied in two basic ways (and soon a third when the CIL (Common Intermediate Language) development is complete):
    • as source code written using the SELinux Policy Language. This is how the simple policies have been written to support the examples in this Notebook, however it is not recommended for real-world policy development.
    • using the Reference Policy that uses 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.
  • To be able to compile and link the source code then load it into the security server requires a number of tools (top of the diagram). These are used to build the sample policy modules where their use is described.
  • To enable system administrators to manage the policy, the SELinux environment and label file systems requires tools and modified GNU / Linux commands.
  • 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.

  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.