Mandatory Access Control Showdown: SELinux, AppArmor, and Seccomp Tested Against Real Attack Vectors
Every Linux security conversation eventually arrives at the same uncomfortable question: are your access controls actually stopping anything, or are they a compliance checkbox dressed up as a threat model? At DistroReviews, we take that question seriously. This evaluation puts three of the most widely deployed Linux security enforcement mechanisms — SELinux, AppArmor, and seccomp — through structured testing across production-representative workloads, measuring both their defensive efficacy and the operational cost they impose on engineering teams.
We conducted testing on identical bare-metal hardware running RHEL 9.3, Ubuntu 22.04 LTS, and Debian 12, each configured with their respective default security frameworks and then tuned to recommended hardening baselines. Threat simulation used a combination of container escape attempts, privilege escalation exploits derived from publicly disclosed CVEs, and syscall abuse patterns sourced from recent malware samples.
Understanding the Fundamental Differences
Before benchmarks, framing matters. SELinux, AppArmor, and seccomp are not interchangeable tools competing for the same job — they operate at different layers of the kernel's security stack and are most effective when understood in that context.
SELinux (Security-Enhanced Linux) implements type enforcement through a labeling system applied to every file, process, and socket on the system. Developed originally by the NSA and now maintained upstream in the Linux kernel, it enforces policy at the kernel level regardless of what a process believes its privileges to be. On RHEL and Fedora, it ships enforcing by default. The policy language is notoriously dense, which has historically driven administrators to disable it rather than learn it — a pattern that persists in production environments far more than most security teams would care to admit.
AppArmor takes a path-based approach, confining applications through profiles that define which files, capabilities, and network resources a given binary may access. Ubuntu, SUSE, and Debian ship AppArmor as their default MAC framework. Its profile syntax is substantially more approachable than SELinux's, and tools like aa-genprof lower the barrier to writing custom profiles from scratch. The trade-off is a less granular enforcement model — path-based confinement can be circumvented by applications that manipulate file paths in ways that label-based systems handle more robustly.
Seccomp (Secure Computing Mode) operates at the syscall filtering layer rather than the file or process label layer. It does not replace SELinux or AppArmor; it reduces the kernel attack surface by restricting which system calls a process is permitted to invoke. Docker and Kubernetes both apply seccomp profiles by default, and the framework is fundamental to modern container security. Alone, seccomp does not prevent a compromised process from reading files it should not access — but paired with a MAC framework, it significantly narrows the exploitable syscall interface.
Threat Simulation Results
Container Escape Scenarios
We attempted four documented container escape techniques against containerized workloads on each platform. On RHEL 9.3 with SELinux enforcing, all four attempts were blocked at the policy enforcement layer before reaching the host filesystem. The kernel audit log provided precise, actionable denial records in each case. On Ubuntu 22.04 with AppArmor active but using the default Docker profile, two of the four techniques were blocked; the remaining two succeeded in accessing host paths because the default Docker AppArmor profile does not restrict all relevant mount operations. Applying the CIS Docker Benchmark AppArmor profile closed those gaps, though it required manual intervention.
Seccomp-only configurations (AppArmor and SELinux both disabled) blocked one of the four techniques outright by restricting the unshare syscall. The other three succeeded.
Privilege Escalation via SUID Binary Abuse
We simulated exploitation of a vulnerable SUID binary — a realistic scenario given the frequency of such CVEs in the NVD. SELinux confined the binary to its assigned domain, preventing the escalated process from writing to /etc/passwd or spawning a shell with elevated context. AppArmor, when a profile was active for the binary, similarly blocked the write attempt. However, AppArmor provides no confinement for binaries without an explicit profile — a significant operational gap for custom or third-party software that your team has not yet profiled.
This distinction is critical for DevOps teams deploying heterogeneous application stacks: SELinux enforces a default deny posture through its targeted policy, while AppArmor's protection is bounded by the profiles you have written.
Syscall Abuse Patterns
Using syscall sequences extracted from recent Linux-targeting malware (specifically, patterns resembling those used by cryptomining payloads and rootkit loaders), we tested seccomp filter effectiveness in isolation. A well-tuned seccomp profile blocked 100% of the tested patterns. The default Kubernetes seccomp profile (RuntimeDefault) blocked approximately 67% of them. The gap is attributable to syscalls that remain permitted in the default profile for broad application compatibility — ptrace and perf_event_open among them.
The takeaway is unambiguous: default profiles are a starting point, not a destination.
Performance Overhead: What Security Actually Costs
We measured application throughput and latency across a web server workload (nginx serving static content under wrk load), a PostgreSQL read-heavy benchmark, and a Python-based data processing pipeline.
| Framework | nginx req/s (vs. baseline) | PostgreSQL latency delta | Python pipeline overhead |
|---|---|---|---|
| SELinux (enforcing) | -2.1% | +1.8ms avg | -1.4% |
| AppArmor (enforcing) | -0.9% | +0.7ms avg | -0.6% |
| Seccomp (custom profile) | -0.4% | +0.3ms avg | -0.3% |
| All three combined | -3.1% | +2.6ms avg | -2.0% |
The overhead is real but modest. For the overwhelming majority of production workloads, the combined performance cost of running all three layers simultaneously falls well within acceptable margins. Teams citing performance as a reason to disable SELinux should revisit those measurements — the 2-3% throughput reduction is rarely the bottleneck in a real-world system.
Deployment Considerations for DevOps Teams
Operationally, AppArmor wins on accessibility. Profile generation tooling, readable syntax, and Ubuntu's dominant position in cloud and container deployments make it the path of least resistance for teams without a dedicated security engineer. That accessibility comes with the coverage gaps described above.
SELinux rewards investment. Teams willing to learn the policy model — or willing to leverage tools like udica for generating container-specific policies — get a meaningfully more comprehensive enforcement posture. RHEL's inclusion of pre-tuned policies for common server roles reduces the initial configuration burden considerably.
Seccomp belongs in every container deployment regardless of which MAC framework runs beneath it. The Kubernetes SeccompProfile API, now stable as of 1.19, makes per-workload profiles manageable at scale. There is no credible argument for running containers in production without at least the RuntimeDefault seccomp profile applied.
The Verdict
No single framework wins unconditionally. For teams operating on RHEL or Fedora in regulated industries — healthcare, finance, federal contracting — SELinux enforcing mode with a maintained policy is the appropriate default. For teams running Ubuntu-based container infrastructure at scale, AppArmor combined with carefully tuned seccomp profiles provides a defensible and operationally sustainable posture.
What is not defensible is disabling any of these mechanisms because they are inconvenient to configure. The threat data is unambiguous: lateral movement and privilege escalation attempts are routine in cloud-hosted Linux environments. The question is not whether your enforcement layer will be tested. It is whether it will hold when it is.
