Configuring the SELinux Policy

Stephen Smalley

Initial: February 2002, Last revised: January 2003


Table of Contents
1. Introduction
2. Architectural Concepts and Definitions
2.1. Flask Concepts
2.2. Flask Definitions
3. Security Model
3.1. TE Model
3.2. RBAC Model
3.3. User Identity Model
4. Policy Language and the Example Policy Configuration
4.1. TE and RBAC Configuration Overview
4.2. TE Statements
4.2.1. Attribute Declarations
4.2.2. Type Declarations
4.2.3. TE Transition Rules
4.2.4. TE Change Rules
4.2.5. TE Access Vector Rules
4.2.6. TE Access Vector Assertions
4.2.7. Unused TE Rules
4.2.8. Example TE Configuration
4.3. RBAC Statements
4.3.1. Role Declarations and Dominance
4.3.2. Role Allow Rules
4.3.3. Obsolete RBAC Rules
4.3.4. Example RBAC Configuration
4.4. User Declarations
4.5. Constraint Definitions
4.6. Security Context Specifications
4.6.1. Initial SID Contexts
4.6.2. Filesystem Labeling Behaviors
4.6.3. Genfs Contexts
4.6.4. Network Object Contexts
4.7. File Contexts Configuration
5. Building and Applying the Policy
5.1. Compiling and Loading the Policy
5.2. Applying the File Contexts Configuration
6. Security-Aware Applications
6.1. Modified Daemons
6.2. New Utilities
6.3. Modified Utilities
6.4. Application Configuration Files
6.4.1. Default_Contexts
6.4.2. Default_Type
6.4.3. Initrc_Context
6.4.4. Passwd_Context and Shadow_Context
7. Customizing the Policy
7.1. Adding Users
7.2. Adding Permissions
7.3. Adding Programs to an Existing Domain
7.4. Creating a New Domain
7.5. Creating a New Type
7.6. Creating a New Role
References

1. Introduction

NSA Security-Enhanced Linux (SELinux) is an implementation of a flexible and fine-grained mandatory access control (MAC) architecture called Flask in the Linux kernel[LoscoccoFreenix2001]. SELinux can enforce an administratively-defined security policy over all processes and objects in the system, basing decisions on labels containing a variety of security-relevant information. The architecture provides flexibility by cleanly separating the policy decision-making logic from the policy enforcement logic. The 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] and Role-Based Access Control (RBAC)[FerraioloNCSC1992]. These two security models also 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 server. Section 2 explains concepts defined by the Flask architecture that are important to configuring the policy. Section 3 describes the security model implemented by the example security server. The policy language and the example policy configuration are described in Section 4. Section 5 explains how the policy is built and applied to the system. Security-aware applications and their configurations are discussed in Section 6. Section 7 describes how to customize the policy for various purposes.

This report has not been updated yet to reflect the reworking of the SELinux module by NSA for inclusion in mainline Linux 2.6, or other recent changes to SELinux. Stay tuned for further updates.