OS Security Hardening: SELinux, AppArmor, and seccomp Explained

In the world of Linux security, traditional Unix permissions (read, write, execute) are like a single lock on the front door. Once a user or process is authenticated, they can access almost any resource within their user ID's scope. But what if a vulnerability allows an attacker to execute code as a legitimate user? That's where Mandatory Access Control (MAC) systems like SELinux and AppArmor come in. They enforce security policies that restrict what processes can do, regardless of the user's identity. Additionally, seccomp (secure computing mode) limits the system calls a process can make, drastically reducing the kernel attack surface. These three tools are the backbone of modern Linux security, used in everything from Android to cloud containers. In this tutorial, you'll learn how they work, how to configure them, and how to debug issues when they block legitimate operations. We'll also walk through a real-world production incident where a misconfigured SELinux policy caused a major outage, and how to avoid similar pitfalls.

What is SELinux?

SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) system built into the Linux kernel. It was originally developed by the NSA to enforce the principle of least privilege. Every process and file has a security context (e.g., user:role:type:level). SELinux policies define rules that allow or deny operations based on these contexts. For example, a web server process with type httpd_t can only read files labeled httpd_sys_content_t. Even if the process runs as root, it cannot access files with a different label. This confinement limits damage from exploits. SELinux can run in enforcing mode (deny and log), permissive mode (log only), or disabled. Most Linux distributions (RHEL, Fedora, CentOS) ship with SELinux enabled by default.

# Check SELinux status
sestatus

# List security context of a file
ls -Z /var/www/html/index.html

# Temporarily set SELinux to permissive (for debugging)
sudo setenforce 0

# Restore default context for a file
sudo restorecon -v /var/www/html/index.html

# View recent denials
sudo ausearch -m avc -ts recent

What is AppArmor?

AppArmor (Application Armor) is another MAC system, but it uses path-based profiles instead of security labels. Each profile defines what files, capabilities, and network access a program can have. For example, a profile for /usr/sbin/nginx might allow read access to /var/www/html/ and write access to /var/log/nginx/. AppArmor is simpler to configure than SELinux and is the default on Ubuntu and Debian. Profiles can be in enforce mode (deny and log) or complain mode (log only). AppArmor is often used in container runtimes like LXD and Docker (via AppArmor profiles).

# Check AppArmor status
sudo aa-status

# List loaded profiles
sudo aa-status | grep 'profiles are in'

# Set a profile to complain mode
sudo aa-complain /usr/sbin/nginx

# Set a profile to enforce mode
sudo aa-enforce /usr/sbin/nginx

# View AppArmor denials in syslog
grep apparmor /var/log/syslog

What is seccomp?

seccomp (secure computing mode) is a Linux kernel feature that restricts the system calls a process can make. It is not a MAC system; it operates at the syscall level. seccomp can be used in two modes: strict mode (only read, write, exit, sigreturn) and filter mode (using BPF to define allowed syscalls). seccomp is commonly used in container runtimes (Docker, runc) to reduce the kernel attack surface. For example, a container might be allowed to call open, read, write, but not mount or reboot. If a process attempts a blocked syscall, it is killed with SIGSYS or the syscall fails with an error. seccomp is essential for sandboxing untrusted code.

# Check if seccomp is enabled in kernel
cat /proc/sys/kernel/seccomp/actions_avail

# List seccomp filters for a running process (requires root)
sudo cat /proc/1234/status | grep Seccomp

# Example: run a Docker container with a custom seccomp profile
docker run --security-opt seccomp=myprofile.json nginx

# Simple seccomp profile (allow common syscalls)
echo '{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {"names": ["read", "write", "open", "close", "stat", "fstat", "lstat", "poll", "mmap", "munmap", "brk", "rt_sigaction", "rt_sigprocmask", "nanosleep", "clock_gettime", "getpid", "exit", "exit_group"], "action": "SCMP_ACT_ALLOW"}
  ]
}' > myprofile.json

Comparing SELinux, AppArmor, and seccomp

While all three enhance security, they operate at different layers. SELinux and AppArmor are MAC systems that control access to files, capabilities, and inter-process communication. seccomp controls system calls. SELinux uses labels and a centralized policy; AppArmor uses path-based profiles; seccomp uses BPF filters. SELinux is more complex but offers finer granularity (e.g., type enforcement, multi-level security). AppArmor is simpler and easier to manage. seccomp is lightweight and often used in containers. In practice, you might use SELinux or AppArmor for host-level confinement and seccomp for additional syscall filtering in containers.

Practical Configuration Examples

Let's walk through a practical scenario: securing a web server. We'll configure SELinux to allow Apache to read files in /var/www/html and connect to a database. Then we'll create an AppArmor profile for the same. Finally, we'll add a seccomp filter for the Apache process. For SELinux, we need to ensure the file context is httpd_sys_content_t and enable the httpd_can_network_connect boolean. For AppArmor, we create a profile in /etc/apparmor.d/usr.sbin.httpd. For seccomp, we use a Docker container with a custom profile.

# SELinux: allow Apache to connect to network
sudo setsebool -P httpd_can_network_connect on

# Ensure correct context
sudo chcon -t httpd_sys_content_t /var/www/html/index.html

# AppArmor: create a profile for Apache
sudo aa-genprof /usr/sbin/httpd
# Follow prompts to generate profile

# seccomp: run Apache in Docker with custom profile
docker run -d --name web --security-opt seccomp=web_profile.json -p 80:80 httpd

Debugging and Troubleshooting

When an application fails due to SELinux, AppArmor, or seccomp, the symptoms often look like permission errors. For SELinux, check /var/log/audit/audit.log with ausearch. Use audit2why to get a human-readable explanation. For AppArmor, check /var/log/syslog or dmesg. Use aa-status to see profile modes. For seccomp, check dmesg for 'seccomp' messages. Temporarily set SELinux to permissive or AppArmor to complain to identify the exact denial. For seccomp, use strace to see which syscall is blocked. Always revert to enforcing/enforce mode after debugging.

# SELinux: find denials
sudo ausearch -m avc -ts recent | audit2why

# AppArmor: check denials
sudo grep apparmor /var/log/syslog | tail -20

# seccomp: check kernel messages
sudo dmesg | grep seccomp

# Temporarily disable SELinux (debug only)
sudo setenforce 0
# After debugging, re-enable
sudo setenforce 1

# Temporarily set AppArmor to complain
sudo aa-complain /usr/sbin/httpd
# Re-enforce
sudo aa-enforce /usr/sbin/httpd