Introduction to SELinux and Mandatory Access Control
Security-Enhanced Linux (SELinux) is a powerful security architecture that brings Mandatory Access Control (MAC) to the Linux kernel. Unlike the traditional Discretionary Access Control (DAC) model, where users and processes decide what they can access, SELinux enforces centrally defined security policies that even the root user must obey. This fundamental shift in control significantly reduces the impact of misconfigurations, compromised applications, and privilege escalation attacks.
At its core, SELinux labels every subject (process) and object (file, directory, socket, device, etc.) in the system, and then governs their interactions through a set of rules called a policy. These rules define exactly who can do what, where, and when, creating a tightly controlled environment that makes exploitation much harder.
DAC vs. MAC: Why Traditional Permissions Are Not Enough
Conventional Unix-style permissions and access controls operate under the Discretionary Access Control model. In DAC, the owner of an object controls its permissions and can grant or revoke access at will. While simple and convenient, this model has several limitations:
- Root can do anything: If an attacker gains root access, they can bypass nearly all checks and control the entire system.
- Compromised applications inherit user power: A vulnerable service running as a privileged user can freely access resources that user controls.
- Limited granularity: Traditional permissions focus on owner, group, and others, and are not designed to express complex security relationships or contextual rules.
Mandatory Access Control, as implemented by SELinux, addresses these weaknesses by centralizing policy decisions. Access is not left to individual users or processes; instead, a global policy determines allowed actions. Even if a program runs as root, SELinux can still restrict its capabilities to the minimal set required to perform its job.
Core Concepts in SELinux
To understand how SELinux improves security, it is useful to break down its key building blocks. While the internals can be intricate, the basic concepts are straightforward and highly structured.
Security Contexts and Labels
Every process and resource in an SELinux-enabled system has a security context. A typical context looks like:
user_u:role_r:type_t:s0
This context contains several elements:
- SELinux user: Not the same as the Unix user; it defines which roles and domains a subject may enter.
- Role: Part of Role-Based Access Control (RBAC), grouping together what a user or process can do.
- Type (or domain): The most important field for everyday policy; it defines what a process is allowed to access and which files it can interact with.
- Level: Used in Multi-Level Security (MLS) or Multi-Category Security (MCS) policies to add sensitivity labels or categories.
For processes, the context is often referred to as a domain. For objects like files or directories, the type field is often called a type label. SELinux policy controls which domains can access which types, and how.
Types, Domains, and Type Enforcement
The heart of SELinux is Type Enforcement (TE). Each process runs in a domain (a specific type assigned to processes), and each resource has its own type. Policy rules describe whether a domain may read, write, execute, or otherwise interact with an object type.
For example, a web server may run in a domain such as httpd_t, while web content files are labeled with types such as httpd_sys_content_t. The policy explicitly allows processes in httpd_t to read content of type httpd_sys_content_t, but not to modify it, and it denies access to unrelated files.
Roles and Users
SELinux also supports a Role-Based Access Control layer, which associates SELinux users with roles and roles with domains. In typical deployments, administrators and regular users are mapped to SELinux users that limit which domains their processes can assume. This extra layer makes it harder for an attacker to jump between different administrative contexts.
How SELinux Enforces Policy
SELinux operates as part of the Linux kernel and is consulted for every security-relevant action. When a process attempts to access a resource, the kernel asks SELinux whether the requested operation is allowed under the current policy.
Access Vector Cache and Decisions
To keep performance reasonable, SELinux maintains an Access Vector Cache (AVC). When a new access request appears, the system looks up the relevant rule in the policy and caches the decision. Repeated similar requests can then be allowed or denied quickly using the cached result. If the policy changes, the cache is invalidated or updated to ensure consistency.
Enforcing, Permissive, and Disabled Modes
SELinux can be configured to run in three main modes:
- Enforcing: Policy rules are fully applied. Unauthorized operations are blocked, and denials are logged.
- Permissive: Policy violations are logged but not denied. This mode is useful for testing new policies or troubleshooting.
- Disabled: SELinux is turned off, and no SELinux checks are performed.
Many administrators begin by running SELinux in permissive mode to understand how existing applications interact with the policy before moving to enforcing mode in production.
Benefits of Using SELinux
Adopting SELinux in your infrastructure provides tangible security advantages that go beyond basic hardening. These benefits are particularly visible in complex environments where multiple services and users coexist on shared systems.
Containment of Compromised Services
If an attacker exploits a vulnerability in a network-facing service, SELinux can sharply limit what the compromised process can do. Because SELinux confines the process to a narrow domain with access only to specific types of resources, the attacker's ability to pivot, read sensitive files, or alter system configuration is dramatically reduced.
Least Privilege in Practice
SELinux policies embody the principle of least privilege. Each service or application is granted only those permissions that are strictly necessary. Instead of trusting every root-level process implicitly, SELinux enforces a fine-grained permission model that minimizes the damage caused by bugs and misconfigurations.
Separation of Duties and Clear Boundaries
Role-based controls and domain separation help create clear boundaries between administrative tasks. A process used for database administration should not be able to act as a web server, and a backup process does not need unrestricted access to authentication secrets. SELinux makes these separations explicit and enforceable.
Common SELinux Workflows for Administrators
While SELinux policy development can become very detailed, most day-to-day administrative work follows a few recurring workflows. Understanding these patterns helps make SELinux manageable and predictable.
Labeling and Relabeling Files
File labels must align with the intended use of each path. When files are moved, restored from backup, or created outside a package manager, their labels may not match the policy. Administrators routinely:
- Inspect existing labels using tools such as
ls -Z. - Restore default labels with utilities that apply the policy's file context definitions.
- Define custom labeling rules when new directories or applications are introduced.
Analyzing and Resolving Denials
In enforcing mode, SELinux will deny unauthorized actions and log them. Administrators review these denials to determine whether they represent legitimate activity that needs policy adjustment, or whether they reveal suspicious behavior.
A typical workflow is:
- Identify the denial event in the log system.
- Determine which domain and type were involved.
- Decide whether to relabel resources, adjust application configuration, or write additional policy rules.
- Test the changes in permissive or enforcing mode before deploying widely.
Balancing Usability and Security
SELinux policies strive to balance security with operational practicality. When configured thoughtfully, SELinux often runs unobtrusively in the background, intervening only when applications attempt unapproved actions. The goal is not to block work, but to ensure that work happens through clearly defined, controlled paths.
Design Principles Behind SELinux
SELinux originated from research into how to build systems that can be trusted to enforce security policies even under hostile conditions. Several design principles guide its architecture:
- Complete mediation: Every access to a protected resource is checked against the policy, avoiding blind spots where an attacker might operate unchecked.
- Least privilege: Components are granted only the permissions they absolutely require.
- Separation of policy and mechanism: The kernel enforces rules, while the rules themselves are defined in policy files that can be created, audited, and revised without modifying the kernel.
- Configurability: Different environments can define different policies, from very strict to more flexible, without changing the underlying enforcement engine.
SELinux in Modern Linux Distributions
Many mainstream Linux distributions provide SELinux as an integral component, often enabled by default with carefully tuned policies. System packages ship with predefined types and contexts that describe how services are supposed to interact with the rest of the system.
Administrators can often start with the distribution's default policy set and refine it for their specific deployment. Over time, these policies have matured and are designed to cover common services, making it easier to adopt SELinux without having to write everything from scratch.
Best Practices for Deploying SELinux
Deploying SELinux effectively involves both technical configuration and organizational discipline. The following practices help ensure that SELinux improves security without disrupting operations:
- Plan phased adoption: Begin in permissive mode on non-critical systems, analyze denials, and only then move to enforcing mode.
- Use default policies where possible: Distribution-provided policies are well tested and usually cover most standard services.
- Document local customizations: When adding site-specific rules or labels, maintain clear documentation so that future upgrades and audits remain understandable.
- Train administrators: Ensure that the team understands basic SELinux concepts, logging, and troubleshooting methods.
SELinux as a Foundation for Defense in Depth
SELinux is not a standalone solution for all security problems, but it is a powerful layer in a defense-in-depth strategy. Combined with secure coding practices, network segmentation, up-to-date software, and strong authentication, SELinux helps ensure that even when something goes wrong, the potential damage is kept to a minimum.
By confining services, enforcing strict boundaries, and centralizing policy decisions, SELinux turns the Linux kernel into an active participant in security rather than a passive bystander. For environments where confidentiality and integrity truly matter, this form of mandatory access control is an essential tool.