In enterprise Linux systems engineering, traditional Discretionary Access Control (DAC)—the venerable model of user, group, and other permissions (chmod 755, chown root:root)—has long ceased to be an adequate security boundary. If an unprivileged web server process (such as Nginx or PHP-FPM) suffers a remote code execution vulnerability, an attacker who compromises that process inherits all file permissions of that user. If an attacker achieves local privilege escalation to root (UID 0), DAC is completely neutralized; the attacker commands unfettered access to the entire operating system. To enforce absolute defense-in-depth, Linux administrators must enforce Mandatory Access Control (MAC) via Linux Security Modules (LSM). In this arena, two titans dominate: AppArmor and Security-Enhanced Linux (SELinux).

What Is the Difference Between AppArmor and SELinux?

The philosophical divergence between these two security frameworks dictates how administrators deploy, audit, and debug systems. AppArmor operates on the principle that security should be simple, human-readable, and tied to binary executable paths. When you write an AppArmor profile for /usr/sbin/nginx, you explicitly define which filesystem paths the binary can read (r), write (w), or execute (x), along with network capability rules (e.g., network inet stream). If a compromised Nginx process attempts to read /etc/shadow or execute /bin/bash, the Linux kernel halts the syscall immediately, even if Nginx is running as root. Crucially, because AppArmor evaluates path strings, moving or renaming a file changes its access rules immediately without relabeling disk sectors.

SELinux, originally developed by the National Security Agency (NSA) and Red Hat, operates on a fundamentally lower, more robust level of abstraction: inode labels and Type Enforcement. In SELinux, files do not have security policies attached to their file paths; every single file, directory, socket, process, and device node possesses a security context label stored in the filesystem’s extended attributes (e.g., system_u:object_r:httpd_sys_content_t:s0). The kernel’s security engine evaluates whether a process running with domain type httpd_t is authorized to access an object labeled httpd_sys_content_t. Even if a rogue admin creates a hardlink or moves a file to /tmp, the file retains its security context label, preventing path-traversal bypass attacks.

AppArmor vs SELinux: Architectural Comparison Matrix

Comparing enforcement models, configuration complexity, container runtime integration, and audit workflows:

The Dangerous “setenforce 0” Habit: Troubleshooting Without Disabling Security

In the enterprise systems world, there is a notorious running joke: the most common command in enterprise Linux is setenforce 0. When a junior sysadmin deploys a new service (such as Apache, PostgreSQL, or an internal Python API) and encounters an inexplicable “Permission Denied” error despite permissions being set to 777, they disable SELinux completely, gutting the server’s primary security barrier.

Mastering modern Linux hardening requires understanding how to troubleshoot denials without disabling enforcement:

• Use Permissive Mode for Profiling: Instead of disabling the security subsystem, switch the target profile into Permissive / Complain mode. Under AppArmor, execute aa-complain /usr/sbin/service; under SELinux, set the domain to permissive via semanage permissive -a httpd_t. In permissive mode, the kernel allows the denied syscalls to execute normally but logs every violation to the audit log.
• Automated Rule Generation: After running your application through a complete functional test in complain mode, use automated tooling to generate the missing rules:
  • In AppArmor: Run aa-logprof to interactively review logged denials and append allowed paths to the profile.
  • In SELinux: Run ausearch -m avc -ts recent | audit2allow -M my_custom_service to automatically compile a custom policy module (.pp file), which can be loaded via semodule -i my_custom_service.pp.

Container Security: AppArmor Profiles vs SELinux Multi-Category Security (MCS)

In Kubernetes and Docker environments, MAC provides the vital second layer of container containment. While Linux cgroups and namespaces isolate process tables and network interfaces, they share the host Linux kernel.

SELinux Multi-Category Security (MCS) represents the gold standard in multi-tenant container isolation. When Podman or Docker runs with SELinux enabled, the container runtime assigns a unique randomized category pair (such as c123,c456) to every container process and its mounted volume. Even if an attacker achieves a full container escape through a kernel vulnerability, the container process cannot read files belonging to an adjacent container on the same host because their MCS category labels do not match.

eBPF LSM vs Traditional MAC: The Next Frontier of Runtime Security

While AppArmor and SELinux remain the rock-solid foundations of Linux security modules, modern SecOps engineering is increasingly adopting eBPF (Extended Berkeley Packet Filter) LSM (such as Tetragon and Falco). Traditional MAC models evaluate authorization decisions against pre-compiled static policy matrices. Writing a complex SELinux policy module for an evolving Go or Rust microservice can take weeks of policy authoring.

eBPF LSM allows attaching programmable, sandboxed bytecode directly into the kernel’s LSM hook points (such as security_bprm_check or security_file_open). An eBPF security program can evaluate runtime context dynamically: examining network socket states, process namespaces, and environment variables before issuing a SIGKILL to an offending process. Crucially, eBPF LSM does not replace SELinux; rather, elite security teams run SELinux as the baseline host confinement layer while layering eBPF LSM inside Kubernetes clusters for surgical, sub-millisecond container observability.

SELinux in Kubernetes: Automated udica Policy Generation

One of the historical pain points of running SELinux on container hosts was that standard container policies (container_t) were either too broad or too restrictive. If a containerized Prometheus node-exporter needed to read /proc and /sys on the host, administrators were forced to run the container in full --privileged mode, completely dismantling container isolation.

Red Hat solved this operational crisis with udica, an open-source tool that inspects container inspection JSON files and automatically compiles custom SELinux security profiles. By running podman inspect <container> | udica my_custom_service, udica generates an exact, least-privilege SELinux policy module in seconds, granting the container access only to the exact host directories and capabilities it requires without granting full root privilege.

Wazuh Agent Resource Throttling: Guarding Production Host Workloads

A legitimate concern for systems engineers deploying host agents to production database servers or high-frequency trading instances is the risk of an agent consuming excessive CPU cycles or saturating network interfaces during deep scans. Wazuh provides robust hardware governance throttles directly inside the agent configuration (ossec.conf):

• FIM Database Throttling: Set <max_eps>100</max_eps> (Events Per Second) to cap the maximum event transmission rate, preventing network link saturation during massive batch file writes.
• Process Priority & CPU Limits: In /var/ossec/etc/internal_options.conf, administrators can configure process niceness (e.g., wazuh_modules.cpu_priority=10) and restrict File Integrity Monitoring file reads to a maximum of 50 files per second. This guarantees that file hashing occurs silently in the background, keeping total agent CPU utilization strictly below 1.5% to 2.0% even during aggressive security audits.

Frequently Asked Questions About Linux MAC Hardening

Can I run AppArmor and SELinux simultaneously on the same system?
No. While modern Linux kernels support stacking Linux Security Modules, AppArmor and SELinux both operate as primary, major MAC providers. You can choose only one major MAC module at boot time via kernel parameters (security=apparmor or security=selinux).

Does enabling SELinux degrade server CPU performance?
Negligible. In enterprise production benchmarks, SELinux’s Access Vector Cache (AVC) caches authorization decisions in kernel memory, resulting in an average performance overhead of less than 1% to 2% on modern x86-64 and ARM64 servers.

What is the difference between Enforcing and Permissive modes?
Enforcing mode actively blocks unauthorized operations and logs the violation. Permissive mode permits the unauthorized operation to proceed, but logs an AVC audit denial, allowing administrators to audit software behavior without breaking functionality.

Container Sandboxing & Rootless Runtime Security

Kernel Mandatory Access Control operates as the secondary containment layer beneath container runtimes. Review rootless container architectures in our guide on Rootless Podman vs Docker: Linux Container Security.