From SELinux Wiki
Revision as of 15:48, 3 February 2015 by RichardHaines (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The SELinux Notebook - 4th Edition


This Notebook should help with explaining:

  1. SELinux and its purpose in life.
  2. The LSM / SELinux architecture, its supporting services and how they are implemented within GNU / Linux.
  3. SELinux Networking, Virtual Machine, X-Windows, PostgreSQL and Apache/SELinux-Plus SELinux-aware capabilities.
  4. The core SELinux kernel policy language and how basic policy modules can be constructed for instructional purposes.
  5. An introduction to the new Common Intermediate Language (CIL) implementation.
  6. The core SELinux policy management tools with examples of usage.
  7. The Reference Policy architecture, its supporting services and how it is implemented.
  8. The integration of SELinux within Android - SE for Android.

Note that this Notebook will not explain how the SELinux implementations are managed for each GNU / Linux distribution as they have their own supporting documentation.

While the majority of this Notebook is based on Fedora 20, all additional developments as seen on the SELinux mail list ( up to September '14 have been added.

Notebook Overview

The book and source tarball are available from: from and has the following major sections:

SELinux Overview - Gives a description of SELinux and its major components to provide Mandatory Access Control services for GNU / Linux. Hopefully it will show how all the SELinux components link together and how SELinux-aware applications / object manager have been implemented (such as Networking, X-Windows, PostgreSQL and virtual machines).
SELinux Configuration Files - Describes all known SELinux configuration files with samples. Also lists any specific SELinux commands or libselinux APIs used by them.
SELinux Policy Language - Gives a brief description of each policy language statement, with supporting examples taken from the Reference Policy source. Also an introduction to the new CIL language (Common Intermediate Language).
The Reference Policy - Describes the Reference Policy and its supporting macros.
SE for Android - An overview of the SELinux services used to support Android.
Object Classes and Permissions - Describes the SELinux object classes and permissions.
libselinux Functions - Describes the libselinux library functions.

Notebook Source Overview

To demonstrate some of the SELinux capabilities a supporting Notebook source tarball is available (notebook-source-4.0.tar.gz). The tarball contains directories and READMEs covering the following:

Building a Basic Policy - Describes how to build monolithic, base and loadable policy modules using core policy language statements and SELinux commands. Note that these policies should not to be used in a live environment, they are examples to show simple policy construction. These can be extended with additional modules in kernel policy language and CIL.
Example libselinux applications - This contains over 100 samples that use the libselinux 2.2.1-6 functions. To save typing long context strings it makes use of a configuration file. There are also some supporting policy modules for the F-20 targeted policy to show how the functions work.
Example Android emulator device - This replaces the kernel policy language version with a CIL policy using namespaces. This is built using Android 4.4 AOSP master and will show processes as u:r:kernel.process:s0, u:r:untrusted_app.process:s0:c512,c768. and files as u:r:bluetooth.data_file:s0, u:r:app.data_file:s0:c512,c768 etc..

Notebook Sections

The major sections are:


AV Access Vector
AVC Access Vector Cache
BLP Bell-La Padula
CC Common Criteria
CIL Common Intermediate Language
CMW Compartmented Mode Workstation
DAC Discretionary Access Control
F-20 Fedora 20
FLASK Flux Advanced Security Kernel
Fluke Flux micro kernel Environment
Flux The Flux Research Group (
ID Identification
LSM Linux Security Module
LAPP Linux, Apache, PostgreSQL, PHP / Perl / Python
LSPP Labeled Security Protection Profile
MAC Mandatory Access Control
MCS Multi-Category Security
MLS Multi-Level Security
NSA National Security Agency
OM Object Manager
OTA over the air
PAM Pluggable Authentication Module
RBAC Role-based Access Control
rpm Red Hat Package Manager
SELinux Security Enhanced Linux
SID Security Identifier
SMACK Simplified Mandatory Access Control Kernel
SUID Super-user Identifier
TE Type Enforcement
UID User Identifier
XACE X (windows) Access Control Extension


These give a brief introduction to the major components that form the core SELinux infrastructure.

Term Description
Access Vector (AV) A bit map representing a set of permissions (such as open, read, write).
Access Vector Cache (AVC) A component that stores access decisions made by the SELinux Security Server for subsequent use by Object Managers. This allows previous decisions to be retrieved without the overhead of re-computation.

Within the core SELinux services there are two Access Vector Caches:# A kernel AVC that caches decisions by the Security Server on behalf of kernel based object managers.

  1. A userspace AVC built into libselinux that caches decisions when SELinux-aware applications use avc_open(3) with avc_has_perm(3) or avc_has_perm_noaudit(3) function calls. This will save kernel calls after the first decision has been made.

Domain For SELinux this consists of one or more processes associated to the type component of a Security Context. Type Enforcement rules declared in Policy describe how the domain will interact with objects (see Object Class).
Linux Security Module (LSM) A framework that provides hooks into kernel components (such as disk and network services) that can be utilised by security modules (e.g. SELinux and SMACK) to perform access control checks.

Currently only one LSM module can be loaded, however work is in progress to stack multiple modules).

Mandatory Access Control An access control mechanisim enforced by the system. This can be achieved by 'hard-wiring' the operating system and applications (the bad old days - well good for some) or via a policy that conforms to a Policy. Examples of policy based MAC are SELinux and SMACK.
Multi-Level Security (MLS) Based on the Bell-La & Padula model (BLP) for confidentiality in that (for example) a process running at a 'Confidential' level can read / write at their current level but only read down levels or write up levels. While still used in this way, it is more commonly used for application separation utilising the Multi-Category Security variant.
Object Class Describes a resource such as files, sockets or services.

Each 'class' has relevant permissions associated to it such as read, write or export. This allows access to be enforced on the instantiated object by their Object Manager.

Object Manager Userspace and kernel components that are responsible for the labeling, management (e.g. creation, access, destruction) and enforcement of the objects under their control. Object Managers call the Security Server for an access decision based on a source and target Security Context (or SID), an Object Class and a set of permissions (or AVs). The Security Server will base its decision on whether the currently loaded Policy will allow or deny access.

An Object Manager may also call the Security Server to compute a new Security Context or SID for an object.

Policy A set of rules determining access rights. In SELinux these rules are generally written in a kernel policy language using either m4(1) macro support (e.g. Reference Policy) or the new CIL language. The Policy is then compiled into a binary format for loading into the Security Server.
Role Based Access Control SELinux users are associated to one or more roles, each role may then be associated to one or more Domain types.
Security Server A sub-system in the Linux kernel that makes access decisions and computes security contexts based on Policy on behalf of SELinux-aware applications and Object Managers.

The Security Server does not enforce a decision, it merely states whether the operation is allowed or not according to the Policy. It is the SELinux-aware application or Object Manager responsibility to enforce the decision.

Security Context An SELinux Security Context is a variable length string that consists of the following mandatory components user:role:type and an optional [:range] component.

Generally abbreviated to 'context', and sometimes called a 'label'.

Security Identifier (SID) SIDs are unique opaque integer values mapped by the kernel Security Server and userspace AVC that represent a Security Context.

The SIDs generated by the kernel Security Server are u32 values that are passed via the Linux Security Module hooks to/from the kernel Object Managers.

Type Enforcement SELinux makes use of a specific style of type enforcement (TE) to enforce Mandatory Access Control. This is where all subjects and objects have a type identifier associated to them that can then be used to enforce rules laid down by Policy.