Skip to content

SELinux & AppArmor

Linux system administrators often rely on SELinux (Security-Enhanced Linux) and AppArmor to enforce application-level security policies beyond traditional Unix permissions. Both are Mandatory Access Control (MAC) systems, but they differ significantly in architecture, flexibility, and use cases. Understanding their design principles and trade-offs is critical for securing enterprise environments.

SELinux: Policy-Driven, Complex Control

SELinux, developed by the NSA and integrated into the Linux kernel since 2004, enforces security policies through a type enforcement (TE) model. It uses a label-based approach to restrict processes, files, and network resources based on predefined rules.

Key Features

  • Fine-grained access control: Policies define allowed interactions between processes, users, and system resources.
  • Multi-level security (MLS): Supports mandatory access control with sensitivity labels (e.g., for classified systems).
  • Policy language: Written in a declarative format (e.g., allow httpd_t httpd_sys_content_t:file read;).
  • Enforcement modes: Permissive (logs violations without blocking) or enforcing (blocks unauthorized actions).

Example Use Case

SELinux is ideal for environments requiring strict compliance (e.g., financial systems, government servers). For example, a web server might be restricted to read only specific directories:

# Example SELinux policy rule (in /etc/selinux/policy/modules/audit/audit.te)
allow httpd_t httpd_sys_content_t:file read;

Commands

# Check SELinux status
sestatus

# Temporarily disable enforcement (not recommended for production)
setenforce 0

AppArmor: Path-Based Simplicity

AppArmor, developed by Canonical, uses path-based policies to restrict applications. Instead of labeling processes, it defines allowed file system paths, network ports, and capabilities. Its design prioritizes ease of use and rapid deployment.

Key Features

  • Profile-based policies: Rules are tied to specific programs (e.g., /usr/bin/apache2).
  • Path restrictions: Limits access to files and directories (e.g., /var/www/html/).
  • Capability drops: Restricts privileges like CAP_NET_BIND_SERVICE.
  • User-space enforcement: Policies are managed via /etc/apparmor.d/ and loaded at boot.

Example Use Case

AppArmor is well-suited for cloud environments or services with straightforward security needs. For instance, a web server might be restricted to read only its document root:

# Example AppArmor profile (in /etc/apparmor.d/usr.sbin.apache2)
/var/www/html/ r,

Commands

# Check AppArmor status
aa-status

# Reload a profile without rebooting
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.apache2

Choosing Between SELinux and AppArmor

Feature SELinux AppArmor
Policy Complexity High (requires deep understanding) Low (easier to configure)
Use Case High-security, compliance-driven Quick deployment, cloud workloads
Configuration Manual policy writing Profile-based, less error-prone
Kernel Dependency Required (since 2.6.10) Required (since 2.6.10)

SELinux is better for environments needing strict, customizable policies (e.g., data centers), while AppArmor excels in simpler, faster setups (e.g., containerized services). Both can coexist, but administrators should avoid overcomplicating policies beyond necessity.

Key takeaways

  • SELinux offers granular, policy-driven control but requires expertise to configure effectively.
  • AppArmor provides simpler, path-based security with lower administrative overhead.
  • Choose SELinux for high-security, compliance-critical systems and AppArmor for streamlined, modern workloads.
  • Always test policies in permissive mode before enforcing to avoid service disruptions.