Understanding SELinux and AppArmor Security Modules

Introduction

Security-Enhanced Linux (SELinux) and AppArmor are two widely used Linux kernel security modules that enforce mandatory access control (MAC) beyond standard Unix permissions. This article gives practical, beginner-friendly explanations of how they work, how they differ, and common commands and workflows to manage and troubleshoot them.

What are SELinux and AppArmor?

Both SELinux and AppArmor restrict what processes can do, but they take different approaches. SELinux uses labels (security contexts) placed on files, processes, and other objects and defines policies based on those labels. AppArmor uses path-based profiles that list permitted operations for applications.

Example: check whether SELinux or AppArmor is active

SELinux:

# Check SELinux status
getenforce
# or for full status
sestatus

AppArmor:

# Check AppArmor status (Ubuntu/Debian)
sudo aa-status
# or
systemctl status apparmor

Quick note: Some distributions favor one by default (Fedora/RHEL -> SELinux; Ubuntu/SUSE -> AppArmor), but you can install and use either on many systems.

Key differences and when to choose each

• Enforcement model:
  • SELinux: Label-based, fine-grained, powerful but with a steeper learning curve.
  • AppArmor: Path-based, easier to get started with, simpler to write profiles for specific applications.
• Complexity:
  • SELinux policies can express very detailed rules (network ports, types, roles).
  • AppArmor profiles are typically shorter and easier to audit.
• Use cases:
  • SELinux is commonly used in enterprise environments where centralized, complex policies are valuable.
  • AppArmor is often used on desktops and simpler server setups where ease of configuration matters.

Example: list SELinux file context vs. AppArmor profile location

SELinux:

# Show SELinux context of a file
ls -Z /etc/passwd
# Example output: -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/passwd

AppArmor:

# AppArmor profiles are commonly in /etc/apparmor.d/
ls -l /etc/apparmor.d/
# Example shows profiles like /etc/apparmor.d/usr.bin.firefox

Common commands (Commands table)

Below is a quick reference table of commonly used commands for SELinux and AppArmor. Use these when checking status, switching modes, or generating policy helpers.

Example: switch SELinux to permissive temporarily

# Temporarily allow all denials to be logged but not enforced
sudo setenforce 0
# Check change
getenforce

Example: put an AppArmor profile into complain mode

# Put /usr/bin/nginx profile into complain mode (logs but doesn't block)
sudo aa-complain /usr/sbin/nginx
# Check status
sudo aa-status

Writing and adjusting policies

SELinux: policies are expressive but often best managed with tools. When a denial occurs, audit logs provide hints and tools like audit2allow can generate policy snippets.

Example: investigate SELinux denial and create a module

# View recent SELinux denials from audit
sudo ausearch -m AVC,USER_AVC -ts recent
# Or check audit log
sudo grep AVC /var/log/audit/audit.log | tail -n 20

# Suggest allow rules (review before applying)
sudo audit2allow -a -m myfix > myfix.te
# Build and load the module (example)
sudo checkmodule -M -m -o myfix.mod myfix.te
sudo semodule_package -o myfix.pp -m myfix.mod
sudo semodule -i myfix.pp

AppArmor: profiles are plain text and often easier to edit. Use complain mode to learn what a process does, then refine its profile.

Example: generate a profile using aa-complain and aa-logprof

# Put profile into complain to gather behavior
sudo aa-complain /usr/bin/myapp

# Run myapp to generate logs, then use aa-logprof to build/adjust profile interactively
sudo aa-logprof
# After refining, enforce it
sudo aa-enforce /usr/bin/myapp

Tips:

• Always review auto-generated rules before applying.
• For SELinux, prefer targeted policies (confine specific daemons) over permissive system-wide modes.
• For AppArmor, test profiles in complain mode before enforcing.

Troubleshooting and logs

Both systems write audit messages to the kernel audit facility. Familiarity with log tools helps pinpoint denials.

SELinux troubleshooting example:

# Show SELinux denials (AVC messages)
sudo ausearch -m AVC -ts today
# Human-readable explanation
sudo ausearch -m AVC -ts today | audit2why
# Suggest allow rules
sudo ausearch -m AVC -ts today | audit2allow -M suggested_changes

AppArmor troubleshooting example:

# Show AppArmor messages via journal
sudo journalctl -k | grep apparmor
# Or view syslog
sudo grep apparmor /var/log/syslog | tail -n 50

# Use aa-status for profile state and complaints
sudo aa-status

Common debugging steps:

• Reproduce the action that was denied while monitoring logs.
• Use "complain" or permissive mode to let the app run while collecting evidence.
• Create minimal allow rules or profile entries; prefer least privilege.

Common Pitfalls

• Confusing disablement with permissive mode: setenforce 0 (permissive) logs denials but does not block; disabling SELinux in kernel boot parameters removes all policy enforcement and may leave residual labeling assumptions.
• Applying auto-generated policy without review: audit2allow and aa-logprof are helpers — they can permit overly broad access if used blindly.
• Path-based weaknesses in AppArmor: AppArmor relies on filesystem paths, so renaming or symlinking binaries can bypass intended protections if profiles are not written carefully.

Commands quick cheat sheet (examples compact)

SELinux:

# Status and mode
sestatus
getenforce

# Relabel filesystem (use with caution)
sudo touch /.autorelabel
sudo shutdown -r now

# Temporarily permissive
sudo setenforce 0
# Restore enforce
sudo setenforce 1

AppArmor:

# Status and profiles
sudo aa-status

# Put profile in complain/enforce modes
sudo aa-complain /path/to/bin
sudo aa-enforce /path/to/bin

# Load a profile
sudo apparmor_parser -r /etc/apparmor.d/myprofile

Next Steps

• Try running an application in complain/permissive mode, reproduce denials, and use logs to craft a minimal policy.
• Read your distribution’s SELinux or AppArmor documentation and examples (RHEL/Fedora guides for SELinux, Ubuntu Server/AppArmor docs).
• Practice safe deployment: test policy changes in staging, audit logs regularly, and automate policy deployment when ready.

This tutorial aimed to give practical entry points to understand, configure, and troubleshoot SELinux and AppArmor. Begin with status checks on your system, practice moving profiles into learning mode, and build from small, reviewed policy changes.

👉 Explore more IT books and guides at dargslan.com.