Configuring the SELinux Policy

Configuring the SELinux Policy

Stephen Smalley

NSA

sds@epoch.ncsc.mil

This work supported by NSA contract MDA904-01-C-0926 (SELinux)

Initial: February 2002, Last revised: Feb 2005

NAI Labs Report #02-007

Table of Contents

1. Introduction............................................................................................................................................2

4. Policy Language and the Example Policy Configuration...................................................................7

5. Building and Applying the Policy.......................................................................................................25

7. Customizing the Policy ........................................................................................................................27

References.................................................................................................................................................32

policy decision-making logic is encapsulated within a single component known as the security server

with a general security interface. A wide range of security models can be implemented as security

servers without requiring any changes to any other component of the system.

To demonstrate the architecture, SELinux provides an example security server that implements a

combination of Type Enforcement (TE)[BoebertNCSC1985], Role-Based Access Control

(RBAC)[FerraioloNCSC1992], and optionally Multi-Level Security (MLS). These security models

provide significant flexibility through a set of policy configuration files. An example security policy

configuration was developed to demonstrate how SELinux can be used to meet certain security goals and

to provide a starting point for users [SmalleyNAITR2001][LoscoccoOLS2001].

This technical report describes how to configure the SELinux security policy for the example security

and the transition from monolithic policy to modular/managed policy. Thus, while some of the discussion herein is still applicable,

much has changed in modern SELinux systems.

2. Architectural Concepts and Definitions

The Flask operating system security architecture provides flexible support for mandatory access control

(MAC) policies[SpencerUsenixSec1999]. The SELinux implementation of the Flask architecture is

described in [LoscoccoFreenix2001]. This section discusses concepts defined by the Flask architecture

that are important to configuring the SELinux policy. It then discusses definitions specified by the Flask

architecture that are used by both the policy enforcing code and by the policy configuration.

2.1. Flask Concepts

Every subject (process) and object (e.g. file, socket, IPC object, etc) in the system is assigned a collection

greater efficiency, the policy enforcement code of SELinux typically handles security identifiers (SIDs)

contexts for labeling persistent objects such as files or for labeled networking. A small set of SID values

are reserved for system initialization or predefined objects; these SID values are referred to as initial

SIDs. Kernel SIDs are not exported to userspace; the kernel only returns security contexts to userspace.

However, userspace policy enforcers may have their own SID mappings maintained by the userspace

AVC that is included in libselinux.

When a security decision is required, the policy enforcement code passes a pair of SIDs (typically the

SID of a subject and the SID of an object, but sometimes a pair of subject SIDs or a pair of object SIDs),

and an object security class to the security server. The object security class indicates the kind of object,

e.g. a process, a regular file, a directory, a TCP socket, etc. The security server looks up the security

contexts for the SIDs. It then bases its decision on the attributes within the security contexts and the

object, e.g. the parent directory for file creations. These default labeling decisions can be overridden by

security-aware applications using the SELinux API. In either case, the use of the new label must be

approved by an access decision or the operation will fail.

The policy enforcement code is responsible for binding the labels to subjects and objects in the system.

For transient objects such as processes and sockets, a SID can be associated with the corresponding

kernel object. However, persistent files and directories require additional support to provide persistent

labeling. Security contexts are stored persistently for files and directories using extended attributes,

specifically the security.selinux attribute.

When converting an existing system to using SELinux, the extended attribute values for all files are

typically initialized by a utility called setfiles from a file contexts configuration that specifies security

configuration is not part of the kernel policy and is only used by userspace programs when initializing or

resetting the extended attributes to their install-time values. The extended attribute values are then used at

runtime by the policy enforcing code. The policy configuration is used by the security server and is

needed to obtain security decisions. The policy configuration specifies security decisions based entirely

on security attributes, whereas the file contexts configuration specifies security contexts for files based on

pathnames. Using the pathname is only suitable for initial installation of the file; subsequently, the

security attributes of the file should be tracked during runtime based on policy.

Access decisions specify whether or not a permission is granted for a given pair of SIDs and class. Each

object class has a set of associated permissions defined to control operations on objects with that class.

These permission sets are represented by a bitmap called an access vector. When an access decision is

requested, the security server returns an allowed access vector containing the decisions for all of the

The AVC component provides an interface to the security server to support cache management for policy

changes.

to audit every use of that operation. An auditdeny decision indicates whether a permission check should

be audited when it is denied.

This information is not specific to any particular security model, and should rarely change. Changes to

these files require recompilation of the module and policy, and will typically require updates to the

module and policy to use the new values. These files do not need to be modified to configure the security

model implemented by the example security server.

The meaning of the security classes and access vector permissions in the original SELinux

implementation was described in [LoscoccoNSATR2001] and [LoscoccoFreenix2001]. Changes made

for the LSM-based SELinux implementation are described in [SmalleyModuleTR2001].

The source for these files is located in the policy/flask subdirectory of the policy sources. These files

are installed into /etc/selinux/(targeted|strict)/src/policy/flask and are used when the

policy configuration is compiled. The Flask configuration files are listed in Table 1.

3. Security Model

The example security server implements a security model that is a combination of a Type Enforcement

(TE) model, a Role-Based Access Control (RBAC) model, and optionally a Multi-Level Security (MLS)

model. The TE model provides fine-grained control over processes and objects in the system, and the

RBAC model provides a higher level of abstraction to simplify user management. The optional MLS

model is not (yet) documented in this report. This section describes the TE and RBAC models, and then

discusses the concept of user identity in SELinux.

3.1. TE Model

A traditional TE model binds a security attribute called a domain to each process, and it binds a security

attribute called a type to each object. The traditional TE model treats all processes in the same domain

The SELinux TE model differs from the traditional TE model in that it uses a single type attribute in the

process. A single type can be used both as the domain of a process and as the type of a related object, e.g.