SELinux & AppArmor

Discretionary Access Control (DAC) the standard Unix permission model where owners control their own resources is flexible but fundamentally limited. When a vulnerability in a web server allows an attacker to execute arbitrary code, that code runs with all the privileges of the web server process. If the web server can read /etc/shadow, so can the attacker. This is the problem Mandatory Access Control (MAC) systems address.

SELinux and AppArmor implement MAC in Linux. Instead of allowing processes to control access to their own resources, a centralized policy defines what access is permitted. Even if a web server process is compromised, the security policy can prevent it from reading sensitive files, opening network connections to unexpected destinations, or executing programs. The policy restrictions are independent of what the process owner wants.

These systems represent different approaches to the same problem. SELinux uses label-based enforcement with flexible policies written in a custom language. AppArmor uses path-based profiles that are often simpler to write and understand. Both can dramatically improve security posture, but both require significant understanding to deploy effectively.

Overview

Mandatory Access Control represents a fundamental shift in security philosophy. Under DAC, access control is discretionary because resource owners decide who can access their resources. Under MAC, the operating system enforces access control according to a global policy that users cannot modify. Even root processes are constrained by this policy.

SELinux (Security-Enhanced Linux) was originally developed by the NSA with academic collaborators. It implements MAC through Security Contexts (labels) attached to every process and file. These contexts contain User, Role, Type, and Level components. Policy rules define which contexts can access which other contexts. The type component (in Type Enforcement) is the most commonly used for restricting processes.

AppArmor (Application Armor) takes a different approach. Instead of labels, AppArmor profiles specify allowed access based on file paths. A profile might declare that the program /usr/sbin/nginx can read files in /var/log/nginx/ and bind to TCP ports 80 and 443. Any other access is denied. Path-based profiles are intuitive because they match how people think about file permissions.

The distinction between these systems and standard permissions is crucial. A misconfigured chmod 777 affects only that specific file or directory. An SELinux or AppArmor policy violation is blocked regardless of traditional Unix permissions. Even if a file is world-readable, SELinux can prevent a web server process from reading it.

When to Use / When Not to Use

MAC systems are essential for servers handling untrusted workloads, multi-tenant environments, and compliance-sensitive applications. Government systems, financial services, and healthcare applications often require MAC frameworks for regulatory compliance.

These systems shine when you need defense in depth beyond standard permissions. If your web server gets compromised, MAC can limit what the attacker can do. If your database server is misconfigured, MAC can prevent unauthorized access to sensitive files. The policy provides a safety net that catches mistakes that standard permissions would miss.

However, MAC systems add complexity. Writing and debugging policies requires understanding the system and the workload. False positives can block legitimate operations; false negatives can create security gaps. For simple single-purpose systems where the threat model is well-understood, the overhead may not justify the benefits.

Architecture or Flow Diagram

graph TD
    A[Process Makes Request] --> B{SELinux or AppArmor Active?}

    subgraph SELinux Flow
        B -->|SELinux| C[Get Process Context]
        C --> D[Get Object Context]
        D --> E{Evaluate Policy Rules}
        E -->|Allow| F[Grant Access]
        E -->|Deny| G[Log Violation<br/>Return EPERM]
    end

    subgraph AppArmor Flow
        B -->|AppArmor| H[Find Profile for Program]
        H --> I[Load Profile Rules]
        I --> J{Compare Path + Permissions}
        J -->|Allow| F
        J -->|Deny| K[Log Violation<br/>Return EPERM]
    end

    style G stroke:#ff6b6b
    style K stroke:#ff6b6b

The diagram shows how SELinux and AppArmor handle access requests differently. SELinux evaluates contexts attached to the process and target object against policy rules. AppArmor finds the profile associated with the program being executed and checks if the requested path and permission match the profile rules.

Core Concepts

SELinux Labels and Contexts

Every process and file in SELinux has a security context (label) attached. The context is displayed as four components:

user:role:type:level

User maps Linux accounts to SELinux users. Role provides role-based access control within SELinux. Type (in Type Enforcement, the most common mode) defines what the process can access. Level (for MLS/MCS systems) provides hierarchical sensitivity levels.

A typical Apache process running in an SELinux-targeted policy environment has context:

system_u:system_r:httpd_t:s0

Files in /var/www/html might have context:

system_u:object_r:httpd_sys_content_t:s0

The policy defines that httpd_t processes can read files labeled with httpd_sys_content_t.

SELinux Policy Modes

SELinux operates in three modes:

Enforcing: Policy violations are blocked and logged. This is the production mode.

Permissive: Policy violations are logged but not blocked. Useful for developing and testing policies before enforcement.

Disabled: SELinux is completely off. Not recommended as it requires a reboot to re-enable cleanly.

# Check current mode
getenforce

# Set mode (requires root)
setenforce Enforcing
setenforce Permissive

# Check detailed status
sestatus

# Persistent configuration in /etc/selinux/config

AppArmor Profiles

AppArmor profiles are simpler than SELinux policies. Each profile corresponds to a program and specifies allowed file access, capabilities, and network access.

# Profile for /usr/sbin/nginx
/usr/sbin/nginx {
  # Include base abstractions
  include <abstractions/base>
  include <abstractions/nameservice>

  # Allow read access to web content
  /var/www/** r,

  # Allow read access to log files
  /var/log/nginx/** r,

  # Allow binding to network ports
  network inet stream,

  # Allow executing CGI scripts
  /usr/lib/nginx/** ix,
}

Profiles use path specifications with permissions:

• r - read
• w - write
• x - execute
• k - lock file
• l - link
• * - any access

The ix transition permission means execute but inherit the current profile rather than switch to the executed file’s profile.

Production Failure Scenarios + Mitigations

Scenario: SELinux Blocks Legitimate Service Access

Problem: Service fails because SELinux policy prevents required file access or network operations.

Symptoms: Service fails to start, logs show “SELinux is preventing” messages, audit.log contains AVC denials.

Mitigation: Use audit2allow to generate policy modules for legitimate access patterns. First, confirm the access is legitimate by reviewing logs. Then generate and install a custom policy module. For temporary relief in development, set to permissive mode.

# Find SELinux denial messages
ausearch -m AVC -ts recent | head -20

# Generate policy module from denials
cat /var/log/audit/audit.log | audit2allow -m myapp > myapp.te
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
semodule -i myapp.pp

# Temporary permissive mode for specific type
semanage permissive -a httpd_t

Scenario: AppArmor Prevents Application Access

Problem: Application fails with permission denied despite correct Unix permissions.

Symptoms: Application crashes, dmesg shows AppArmor denials, /var/log/syslog contains AppArmor messages.

Mitigation: Use aa-logprof to update profiles based on application behavior. Run the application in complain mode to generate logs without blocking. Update profiles accordingly.

# Put profile in complain mode (logs but allows)
aa-complain /etc/apparmor.d/usr/sbin.nginx

# After running application, update profile
aa-logprof

# Reload updated profile
apparmor_parser -r /etc/apparmor.d/usr/sbin.nginx

Scenario: Container Access Blocked by Host MAC Policy

Problem: Containerized application fails because host SELinux or AppArmor policy prevents container operations.

Symptoms: Container cannot bind to network port, cannot access mounted volume, operations fail inside container.

Mitigation: Set appropriate SELinux context on container volumes. Use chcon or semanage fcontext to set correct contexts. For AppArmor, ensure container runtime profile allows required access.

# Set SELinux context on volume mount
semanage fcontext -a -t httpd_sys_content_t '/var/www/html(/.*)?'
restorecon -Rv /var/www/html

# For containers, use :Z flag to relabel automatically
docker run -v /var/www/html:/var/www/html:Z nginx

Trade-off Table

Aspect	SELinux	AppArmor
Policy Type	Label-based (Type Enforcement)	Path-based
Complexity	High (custom policy language)	Lower (profile syntax)
Learning Curve	Steep	Moderate
Debugging	Tools like audit2allow, sesearch	aa-logprof, dmesg
Flexibility	Very high (MCS, MLS, RBAC)	Moderate
Default Distribution	RHEL, Fedora, CentOS	SUSE, Ubuntu
Container Support	Excellent (with libvirt)	Native Docker integration

SELinux Component	Purpose	Example
User	Maps Linux users to SELinux users	staff_u for regular users
Role	Role-based access control	system_r for system processes
Type	Process/domain restrictions	httpd_t for web server
Level	Multi-level security (MLS)	s0 to s15:c0.c1023

AppArmor Permission	Meaning
r	Read
w	Write (but not create/delete)
a	Append
x	Execute (own profile)
ix	Execute (inherit current profile)
px	Execute (own profile, with environment)
ux	Execute (unconfined, dangerous)
m	Execute as a mapped file

Implementation Snippets

Checking SELinux Status and Context

#!/bin/bash
# Check SELinux status
echo "=== SELinux Status ==="
sestatus

echo ""
echo "=== Current Process Context ==="
id -Z

echo ""
echo "=== SELinux Context of Files ==="
ls -Z /etc/passwd /etc/shadow

echo ""
echo "=== SELinux Context of Running Services ==="
ps auxZ | grep httpd | head -3

Creating a Simple SELinux Policy Module

# Step 1: Enable SELinux audit logging
ausearch -m AVC -ts recent > avc_logins

# Step 2: Generate policy module
cat avc_logins | audit2allow -M myapp_policy

# Step 3: Review generated policy
cat myapp_policy.te

# Step 4: Compile and install
checkmodule -M -m -o myapp_policy.mod myapp_policy.te
semodule_package -o myapp_policy.pp -m myapp_policy.mod
semodule -i myapp_policy.pp

# Step 5: Verify module loaded
semodule -l | grep myapp_policy

AppArmor Profile for Python Application

# /etc/apparmor.d/usr/local/bin/myapp
/usr/local/bin/myapp {
  include <abstractions/base>

  # Allow reading configuration
  /etc/myapp/** r,

  # Allow reading and writing data
  /var/lib/myapp/** rw,

  # Allow log files
  /var/log/myapp/** rw,
  /var/log/myapp/*.log a,

  # Network access
  network inet stream,
  network inet dgram,

  # Allow tmp files
  /tmp/** rw,
}

Reloading AppArmor Profiles

#!/bin/bash
# Parse and reload all profiles
apparmor_parser -r /etc/apparmor.d/*

# Reload specific profile
apparmor_parser -r /etc/apparmor.d/usr.bin.nginx

# List loaded profiles
apparmor_status | grep profiles

# View profile violations in dmesg
dmesg | grep apparmor

Observability Checklist

SELinux Monitoring:

• Enable auditd to capture AVC (Access Vector Cache) denials
• Monitor /var/log/audit/audit.log for violations
• Track sestatus output for policy state changes
• Alert on permissive domain usage

AppArmor Monitoring:

• Check dmesg for DENIED messages
• Use aa-notify for desktop notifications
• Monitor /var/log/syslog for AppArmor events
• Track profile changes

Compliance Checks:

• Verify mode is Enforcing in production
• Confirm policy modules are loaded
• Check for unexpected permissive domains
• Validate container MAC configuration

Log Analysis:

# SELinux AVC denials in last hour
ausearch -m AVC -ts one hour | tail -30

# AppArmor denied operations
grep DENIED /var/log/syslog | tail -20

# Set up real-time alerting
ausearch -m AVC | tail -5 | while read line; do
  echo "$line" | mail -s "SELinux denial" admin@example.com
done

Security/Compliance Notes

Regulatory Requirements: Many compliance frameworks (FedRAMP, PCI-DSS, HIPAA) require MAC implementation for sensitive systems. SELinux provides comprehensive controls that satisfy these requirements when properly configured.

Defense in Depth: MAC provides a critical layer beyond standard permissions. Even if an attacker gains code execution, MAC policies can prevent lateral movement, data exfiltration, and privilege escalation.

Container Security: MAC systems extend container isolation. SELinux can label container processes and files, preventing container escapes from affecting host resources. AppArmor profiles restrict container capabilities to minimum required.

Policy Hardening: Default policies are often overly permissive for specific workloads. Audit your running services and tighten policies to the minimum required access. Use permissive mode during development to identify required access, then enforce in production.

Common Pitfalls / Anti-patterns

Setting Entire Domain to Permissive: Putting a large domain like httpd_t in permissive mode defeats the purpose of SELinux for all web server processes. Use targeted policy (the default) which keeps enforcing mode for system services while allowing per-domain permissive if needed.

Ignoring Audit Logs: AVC denials that are never addressed indicate policy gaps. Legitimate operations may be blocked, or policy misconfigurations may go undetected. Review and address denial patterns regularly.

Overly Permissive AppArmor Profiles: Profiles that allow /** rwm (read write mount on everything) provide no real security. Start restrictive and add only required exceptions.

Disabling MAC Entirely: When troubleshooting, disabling SELinux or AppArmor entirely creates security gaps and requires reboot to restore. Use permissive mode or complain mode instead.

Not Testing Policy Changes: New policies may have unintended effects on other services. Test in staging with the same workload profile before deploying policy changes to production.

Quick Recap Checklist

• MAC systems enforce centralized security policies independent of owner discretion
• SELinux uses label-based enforcement with User, Role, Type, Level contexts
• AppArmor uses path-based profile enforcement
• Both prevent compromised processes from accessing unauthorized resources
• SELinux is more powerful but has a steeper learning curve
• AppArmor is simpler but less flexible
• Policy development requires understanding the workload
• Production deployment requires comprehensive testing
• Monitoring and logging essential for policy maintenance
• Container MAC configuration extends host security to containers

Interview Questions

Further Reading

• Concurrency Fundamentals — The problem space and why synchronization is needed
• Mutex Implementation — How mutexes are implemented in userspace and kernel
• Semaphores — Counting semaphores for resource management
• Readers-Writer Locks — Optimizing for read-heavy workloads
• Lock-Free Structures — Advanced techniques for highly concurrent systems

Conclusion

SELinux and AppArmor implement Mandatory Access Control to provide defense-in-depth beyond standard Unix permissions. SELinux offers label-based enforcement with User, Role, Type, and Level contexts through the SELinux policy language. AppArmor provides path-based profile enforcement that is often simpler to write and understand. Both prevent compromised processes from accessing resources beyond their policy-granted scope, dramatically limiting the blast radius of vulnerabilities. For continued learning, explore the SELinux policy language in depth, study MLS/MCS systems for multi-level security, and examine how container runtimes integrate with MAC systems.