SELinux: Security-Enhanced Linux

An SELinux system without a policy is like a courtroom without laws—the infrastructure exists, but no decisions can be made. SELinux policies are the comprehensive rule sets that define every permitted interaction between subjects (processes) and objects (files, sockets, devices) in the system.

A typical SELinux policy contains hundreds of thousands of rules, carefully structured to:

• Confine hundreds of applications to their intended scope
• Define valid transitions between security domains
• Specify precisely which actions each process type may perform
• Establish the security boundaries that contain attacks

Understanding SELinux policies is essential for anyone who administers, develops for, or secures Linux systems. This page explores policy architecture from first principles through practical application.

SELinux supports multiple policy types, offering different trade-offs between security guarantees and operational flexibility. Understanding these types is the first step in working with SELinux policies.

Targeted Policy

The targeted policy is the default on Red Hat-derived distributions. It embodies a pragmatic approach:

• Network-facing services are confined — Apache, MySQL, DNS, SSH, and other network daemons run in specific domains with limited permissions
• User processes run unconfined — Regular user applications (desktop apps, shells) run in the unconfined_t domain with minimal restrictions
• Selective protection — Security focus is on high-risk attack surfaces

This approach acknowledges that comprehensive policy for every application is impractical in many environments. The targeted policy protects against the most likely attack vectors—network service compromises—while minimizing user-facing policy issues.

Strict Policy

The strict policy takes a comprehensive approach:

• Everything is confined — No unconfined domains; every process has explicit policy
• Complete least privilege — Each application limited to exactly what it needs
• Higher administrative burden — Every new application requires policy work

Strict policies are used in high-security environments where the additional administrative overhead is justified (government, military, financial systems).

MLS Policy

Multi-Level Security (MLS) policy adds Bell-LaPadula-style security levels:

• Hierarchical security levels — Subjects and objects have sensitivity levels
• Compartments — Additional categorical restrictions (need-to-know)
• Information flow control — Prevents unauthorized disclosure across levels
• Certification requirements — Often required for handling classified data

MLS is used in environments processing classified data at multiple levels (e.g., a system handling both Secret and Top Secret information).

SELinux Modes

Independent of policy type, SELinux operates in one of three modes:

Enforcing Mode

SELinux policy is active and access violations are denied. This is production mode.

Permissive Mode

SELinux logs what would be denied but allows access. Use for debugging and policy development—never in production.

Disabled Mode

SELinux is completely inactive. No policy enforcement, no context labeling. Not recommended.

SELinux policies are composed of several distinct components that work together to define the security model. Let's examine each:

Type Declarations

The foundation of SELinux is types. Every subject (process) and object (file, socket, etc.) has a type. Types are declared in policy:

type httpd_t;           # Type for Apache processes
type httpd_exec_t;      # Type for Apache executable
type httpd_content_t;   # Type for web content files
type httpd_log_t;       # Type for Apache log files
type httpd_config_t;    # Type for Apache config files

Type naming convention: <name>_t for process types (domains), <name>_exec_t for executables, <name>_log_t for logs, etc.

Attributes

Attributes are named groups of types. Rules can reference attributes, applying to all types with that attribute:

attribute domain;        # All process types
attribute file_type;     # All file types
attribute exec_type;     # All executable types
attribute port_type;     # All port types

# Assign types to attributes
typeattribute httpd_t domain;
typeattribute httpd_exec_t exec_type, file_type;

This enables writing rules that apply to categories of types without listing each one.

Access Vector Rules

The heart of policy is access vector (AV) rules that specify what's allowed:

# Basic allow rule syntax:
# allow source_type target_type : object_class permissions;

allow httpd_t httpd_content_t : file { read open getattr };
allow httpd_t httpd_log_t : file { create write append };

Rules can also deny, audit, or conditionally allow access.

Object Classes and Permissions

Object classes represent categories of kernel objects. Each class has a set of applicable permissions:

The complete list comprises over 80 object classes with hundreds of unique permissions.

Writing SELinux policy from scratch would be impractical—a complete system requires policies for hundreds of programs. The Reference Policy solves this by providing a well-structured, modular policy base that distributions customize.

Reference Policy Architecture

The Reference Policy organizes rules into modules, each handling a specific service or subsystem:

refpolicy/
├── policy/
│   ├── modules/
│   │   ├── admin/          # Administrative tools
│   │   │   ├── sudo.te     # sudo rules
│   │   │   ├── sudo.if     # sudo interface
│   │   │   └── sudo.fc     # sudo file contexts
│   │   ├── services/       # System services
│   │   │   ├── apache.te
│   │   │   ├── postgresql.te
│   │   │   └── sshd.te
│   │   ├── kernel/         # Kernel and core
│   │   ├── roles/          # Role definitions
│   │   └── system/         # System components
│   └── support/            # Macros and helpers
├── config/
└── doc/

Each module consists of three files:

• .te (Type Enforcement) — Domain rules and type declarations
• .if (Interface) — Reusable macros for other modules
• .fc (File Contexts) — Path-to-label mappings

The Power of Interfaces

Interfaces are the Reference Policy's key innovation. They encapsulate common access patterns as reusable macros:

# Instead of writing these raw rules:
allow mydaemon_t self:capability { net_bind_service };
allow mydaemon_t mydaemon_port_t:tcp_socket { bind listen accept };
corenet_tcp_bind_port(mydaemon_t, mydaemon_port_t)
...

# You write:
corenet_tcp_bind_generic_port(mydaemon_t)

Interfaces:

• Abstract complexity — Hide dozens of low-level rules behind meaningful names
• Ensure consistency — All modules binding ports do it the same way
• Reduce errors — Battle-tested macros vs. hand-written rules
• Enable reuse — Other modules can call your interfaces

Recompiling policy for every configuration change would be impractical. Policy booleans provide runtime-adjustable policy switches without recompilation.

Understanding Booleans

Booleans are named true/false values that enable or disable sets of rules:

# Policy defines conditional rules:
bool httpd_can_network_connect false;

if (httpd_can_network_connect) {
    corenet_tcp_connect_all_ports(httpd_t)
}

# Administrator enables at runtime:
$ sudo setsebool httpd_can_network_connect on

# Now httpd_t can connect to any port

Booleans enable administrators to:

• Enable optional functionality without policy customization
• Toggle features on/off for testing
• Adapt stock policy to specific use cases

Common Important Booleans

Some booleans have significant security implications:

SELinux policies undergo compilation from human-readable source to an optimized binary format the kernel can efficiently query. Understanding this process helps with policy development and troubleshooting.

The Policy Compilation Pipeline

[Policy Source Files] (.te, .if, .fc)
        ↓
    checkmodule (parses, validates)
        ↓
[Policy Module] (.mod)
        ↓
    semodule_package (packages)
        ↓
[Policy Package] (.pp)
        ↓
    semodule (installs to policy store)
        ↓
[Policy Store] (/var/lib/selinux/targeted/)
        ↓
    semodule/libsemanage (links all modules)
        ↓
[Compiled Binary Policy] (policy.XX)
        ↓
    Kernel loads binary policy

Policy Store and Versions

SELinux maintains a policy store containing all installed modules:

/var/lib/selinux/targeted/
├── active/
│   ├── modules/100/     # Priority 100 (default)
│   │   ├── base/
│   │   ├── httpd/
│   │   ├── sshd/
│   │   └── mydaemon/
│   ├── modules/400/     # Higher priority overrides
│   ├── file_contexts
│   ├── booleans.local
│   └── seusers
└── policy/
    └── policy.33        # Compiled binary (kernel version 33)

Modules have priority levels (100-999). Higher priority modules can override rules from lower ones. This enables local customizations without modifying distribution modules.

The Kernel Policy Interface

The compiled binary policy is loaded into the kernel through the SELinux filesystem:

/sys/fs/selinux/
├── load          # Write policy binary here to load
├── enforce       # Read/write enforcement mode
├── policy        # Read current loaded policy
├── status        # Sequence number for policy changes
├── class/        # Object class definitions
├── booleans/     # Boolean values
└── ...           # Other tunables

When stock policy doesn't meet your needs, you can create custom modules. This section walks through the process for common scenarios.

Scenario: Allowing Denied Access

The most common customization: your application triggers SELinux denials and you need to allow the access. The workflow:

1. Trigger the denial — Run your application and observe the failure
2. Find the denial in audit log — ausearch -m avc -ts recent
3. Analyze the denial — Understand what access is needed
4. Generate policy — Use audit2allow as a starting point
5. Review and refine — Never blindly accept generated rules
6. Install and test — Deploy and verify

Scenario: Confining a New Application

For a new application requiring full confinement:

1. Identify resources — What files, ports, devices does it need?
2. Create types — Domain for the process, types for files
3. Write basic rules — Start minimal, add as needed
4. Define file contexts — Map paths to types
5. Test in permissive — Run with setenforce 0, collect denials
6. Iterate — Add rules for each legitimate denial
7. Deploy in enforcing — Switch to setenforce 1 for production

SELinux provides powerful tools for inspecting and querying policy. Mastering these tools is essential for policy development and troubleshooting.

seinfo: Policy Information

seinfo provides statistics and listings from the loaded policy:

sesearch: Policy Rule Search

sesearch finds specific rules in the policy:

Other Essential Tools

We've explored the architecture and mechanics of SELinux policies. Let's consolidate the key insights:

What's Next:

With policy structure understood, we'll explore Contexts and Labels—the mechanism by which types are assigned to subjects and objects. Understanding labeling is crucial for ensuring policy rules match the resources they're meant to protect.