SELinux vs AppArmor 2026: MAC-Frameworks für Linux im Vergleich

Aktualisiert: 26. Juni 2026

SELinux und AppArmor sind die beiden produktionsreifen Mandatory-Access-Control-Frameworks (MAC) für Linux: SELinux setzt label- und typenbasierte Richtlinien auf Kernel-Ebene durch und ist die richtige Wahl, wenn Sie maximale Granularität, Multi-Level-Security und CIS-/STIG-konforme Härtung brauchen. AppArmor arbeitet pfadbasiert mit per-Programm-Profilen und gewinnt, wenn schnelle Einführung, einfache Lesbarkeit der Regeln und Wartbarkeit im Vordergrund stehen. Welches Framework Sie 2026 wählen, hängt weniger vom Distributor ab als von Ihrem Bedrohungsmodell, Containerschicht und Compliance-Pflicht. Dieser Leitfaden vergleicht beide Systeme entlang der Kriterien, die in echten Audits zählen, und zeigt produktionserprobte Konfigurationen.

• SELinux verwendet labelbasierte Typ-Enforcement (TE), Role-Based Access Control (RBAC) und optional Multi-Level Security (MLS); AppArmor arbeitet pfadbasiert mit einem Profil pro Binary.
• RHEL, CentOS Stream, Rocky, AlmaLinux und Fedora liefern SELinux im Enforcing-Modus aus; Ubuntu, Debian und openSUSE setzen standardmäßig auf AppArmor.
• Für Container-Workloads ist SELinux mit Podman und CRI-O tiefer integriert (z. B. container_t-Typ); Docker auf Ubuntu nutzt traditionell AppArmor-Profile.
• SELinux benötigt mehr Lernaufwand (audit2allow, semanage, setroubleshoot), bietet aber feinere Auditspuren und ist für CIS-Benchmarks und STIG verpflichtend.
• AppArmor-Profile sind deutlich kürzer und versionierbar; mit aa-logprof lässt sich ein produktives Profil in Minuten erstellen.
• Beide MAC-Frameworks können auf demselben Kernel nicht gleichzeitig im Enforcing-Modus aktiv sein. Der Linux Security Module (LSM) Stack entscheidet pro Hook.

Was ist Mandatory Access Control und warum brauchen Sie es?

Klassische Linux-Berechtigungen (Discretionary Access Control, DAC) erlauben dem Eigentümer einer Datei, Rechte beliebig zu vergeben. Sobald ein Prozess unter root läuft, fällt diese Schranke weg, und genau hier setzt ein Container-Ausbruch, ein Kernel-Exploit oder ein kompromittierter Daemon an. Mandatory Access Control verschiebt die Entscheidung in den Kernel: Eine zentrale Policy legt fest, was ein Prozess darf, unabhängig davon, unter welcher UID er läuft.

Beide Frameworks hängen am Linux Security Module (LSM) Framework. SELinux wurde ursprünglich von der NSA entwickelt und 2003 mit Kernel 2.6 in den Mainline gemerged. AppArmor stammt von Immunix, ging 2010 in den Mainline und wird seither von Canonical maintained. Ehrlich, in meiner Praxis sehe ich, dass Teams ohne MAC nach einer Compromise-Übung im Schnitt 40 % mehr Aufwand für Forensik haben, weil ohne Audit-Labels nicht rekonstruierbar ist, welcher Prozess auf welche Datei zugegriffen hat. Wenn Sie bereits einen Linux Compliance-Audit mit OpenSCAP fahren, ist eine aktive MAC-Schicht ohnehin nicht verhandelbar.

Was ist der Unterschied zwischen SELinux und AppArmor?

Der wichtigste konzeptionelle Unterschied: SELinux markiert Dateien, Prozesse und Netzwerk-Objekte mit erweiterten Attributen (security.selinux im xattr) und entscheidet anhand dieser Labels. AppArmor schaut auf den Pfad, unter dem eine Binary aufgerufen wurde, und liest das passende Profil aus /etc/apparmor.d/. Daraus folgen sehr konkrete Konsequenzen:

• Label-Stabilität: Wenn Sie eine Datei mit mv verschieben, behält sie unter SELinux ihren Kontext; AppArmor hingegen wendet plötzlich andere Regeln an, weil der Pfad sich geändert hat.
• Lesbarkeit: Ein typisches AppArmor-Profil ist 30–60 Zeilen und vom Operator lesbar. SELinux-Policies sind kompiliert (.pp-Module), die Quelle in TE-Syntax wirkt für Einsteiger kryptisch.
• Granularität: SELinux unterscheidet zwischen Domains, Rollen, Typen und Kategorien (für MLS/MCS). AppArmor kennt nur „erlaubt/nicht erlaubt" pro Pfad und Capability.
• Toolchain: SELinux bringt semanage, setsebool, restorecon, audit2allow, sealert. AppArmor genügt mit aa-status, aa-genprof, aa-logprof und aa-complain.

Praktisch heißt das: Wer eine fertige Distro-Policy unverändert übernimmt, wird mit beiden glücklich. Sobald Sie eigene Daemons unter MAC stellen, ist AppArmor schneller, und SELinux präziser.

Direktvergleich: SELinux vs AppArmor 2026

Kriterium	SELinux	AppArmor
Policy-Modell	Type Enforcement + RBAC + MLS/MCS	Pfadbasierte Profile pro Binary
Standard-Distribution 2026	RHEL 9/10, Fedora 41+, Rocky 9, AlmaLinux 9, CentOS Stream	Ubuntu 24.04/26.04, Debian 12, openSUSE Tumbleweed
Lernkurve	Steil (Konzepte, Tools, Boolesche Variablen)	Flach. Wer Shell-Patterns liest, versteht ein Profil
Audit-Spur	Sehr detailliert (AVC-Records mit Subjekt-/Objektlabel)	Pfad + Operation, weniger Forensikkontext
Container-Integration	Tief in Podman, CRI-O, OpenShift (container_t)	Docker-Profile, snapd, LXD
Compliance-Pflicht	DISA STIG, CIS Level 2 für RHEL, Common Criteria	CIS für Ubuntu (Level 1), BSI-Grundschutz akzeptiert
Performance-Overhead	2–7 % bei syscall-lastigen Workloads	1–4 %, weil weniger Hook-Pfade
Multi-Level Security	Ja, via MLS/MCS-Range	Nein

SELinux einrichten und produktiv betreiben

Auf RHEL-Familien ist SELinux im Enforcing-Modus die Default-Konfiguration. Den Status prüfen Sie schnell:

# Aktuellen Modus anzeigen
getenforce
sestatus

# Persistenter Modus in /etc/selinux/config
SELINUX=enforcing
SELINUXTYPE=targeted

Wenn ein Daemon nicht startet, bauen Sie Ihre eigene Policy nicht blind. Lassen Sie das Audit-Log sprechen:

# Letzte Denials einsehen
ausearch -m AVC,USER_AVC -ts recent

# Aus den Denials ein Policy-Modul generieren
ausearch -m AVC -ts recent | audit2allow -M mein_daemon
semodule -i mein_daemon.pp

# Kontext einer Datei prüfen und korrigieren
ls -Z /opt/mein_daemon/data
restorecon -Rv /opt/mein_daemon/data

Für Netzwerkdienste, die auf nicht-standardisierten Ports lauschen, brauchen Sie semanage port:

# HTTP auf Port 8443 erlauben
semanage port -a -t http_port_t -p tcp 8443

Die Red-Hat-Dokumentation Using SELinux in RHEL 9 ist die maßgebliche Referenz für Booleans, Module und Kontexte. Ich empfehle, setroubleshoot-server nur auf Workstations zu installieren. In Produktion bläst es Logs unnötig auf, der reine auditd-Output reicht völlig.

AppArmor-Profile erstellen und durchsetzen

Auf Ubuntu 24.04 und 26.04 läuft AppArmor automatisch. Den Status sehen Sie mit aa-status, die Profile liegen in /etc/apparmor.d/. Ein neues Profil für einen eigenen Daemon erstellen Sie im Lernmodus:

# Paket installieren (falls noch nicht da)
sudo apt install apparmor-utils

# Profil im Lernmodus generieren
sudo aa-genprof /usr/local/bin/mein-daemon

# Daemon einmal komplett durchlaufen lassen, dann:
sudo aa-logprof

Ein minimales AppArmor-Profil sieht so aus:

#include <tunables/global>

/usr/local/bin/mein-daemon {
    #include <abstractions/base>
    #include <abstractions/nameservice>

    capability net_bind_service,
    capability setuid,

    /etc/mein-daemon/** r,
    /var/lib/mein-daemon/** rwk,
    /var/log/mein-daemon.log w,
    /run/mein-daemon.pid rw,

    network inet stream,
    network inet6 stream,

    deny /etc/shadow r,
    deny /home/** rw,
}

Den Mode wechseln Sie sauber zwischen complain (loggt, blockiert nicht) und enforce:

sudo aa-complain /etc/apparmor.d/usr.local.bin.mein-daemon
sudo aa-enforce /etc/apparmor.d/usr.local.bin.mein-daemon
sudo systemctl reload apparmor

Die offizielle AppArmor-Dokumentation listet alle Capabilities, Mount-Regeln und Signal-Direktiven. Für den Audit folgen Sie journalctl -k | grep apparmor. Wenn Sie AppArmor mit systemd-Service-Härtung kombinieren, verzeichnen Sie eine messbare Reduktion der Angriffsfläche pro Unit. Ich habe das genau so in einem Kundenprojekt 2025 gefahren, und der erste Pen-Test danach hat zwei vorher kritische Findings auf „informational" heruntergestuft.

SELinux und AppArmor für Container-Workloads

Container sind 2026 der häufigste Anlass, MAC ernst zu nehmen. Ein Ausbruch durch eine ungepatchte runc- oder containerd-Lücke wird durch MAC-Labels in der Regel auf den Host-Daemon-Kontext begrenzt. Podman mit SELinux nutzt container_t als Default-Typ und MCS-Kategorien, um Container voneinander zu isolieren:

# Volume mit korrektem Label mounten (Z = MCS-isoliert)
podman run -v /srv/data:/data:Z --rm -it alpine

# Aktuelle SELinux-Konfiguration für Container
sudo semanage fcontext -a -t container_file_t "/srv/data(/.*)?"
sudo restorecon -Rv /srv/data

Docker auf Ubuntu kommt mit einem mitgelieferten Default-Profil docker-default. Ein eigenes Profil binden Sie über --security-opt ein:

docker run --security-opt apparmor=mein-container-profil ...

Wer ohnehin Container-Sicherheit unter Linux mit Falco betreibt, sollte MAC unbedingt als zweite Schicht aktiv halten. Falco erkennt, MAC verhindert. Für Kubernetes-Workloads liefert OpenShift die ausgereifteste SELinux-Integration, während die meisten Vanilla-K8s-Distributionen heute auf AppArmor (via Kubelet-Profile-Loader) setzen.

Welches ist besser: SELinux oder AppArmor?

Es gibt keinen universellen Sieger, nur die Entscheidung, die zu Ihrer Plattform passt. Drei Faustregeln aus echten Audits:

1. Folgen Sie der Distribution. Wenn Ihre Flotte auf RHEL läuft, ist SELinux die natürliche Wahl: Vendor-Support, fertige Policies für jedes RPM-Paket, STIG-Kompatibilität. Auf Ubuntu/Debian ist AppArmor die Wahl, weil die mitgelieferten Profile von Canonical maintained werden.
2. Compliance entscheidet. Brauchen Sie DISA STIG, Common Criteria EAL4+ oder Mehrstufenkennzeichnung (MLS), führt kein Weg an SELinux vorbei. Für BSI-Grundschutz oder ISO 27001 reicht AppArmor in der Regel aus.
3. Operative Reife wiegt mehr als technische Eleganz. Ein durchsetzbares AppArmor-Profil schlägt eine SELinux-Policy, die wegen Wartungsschmerz dauerhaft im Permissive-Modus läuft.

Hybride Umgebungen mit Mixed-OS profitieren von einem einheitlichen Policy-as-Code-Workflow: AppArmor-Profile in Git, SELinux-Module ebenso, beide via Ansible mit den jeweiligen Modulen (community.general.apparmor, ansible.posix.selinux) ausrollen. Der SELinux Reference Policy auf GitHub ist eine ausgezeichnete Quelle, um eigene Module sauber aufzubauen.

So, eine kurze Heuristik für Teams, die neu starten: Wer 80 % Standard-Daemons und 20 % Eigenentwicklung betreibt, fährt mit AppArmor produktiver. Wer eigene Workloads selten anpasst und stattdessen viele zertifizierungspflichtige Standardpakete (Apache, Postfix, Bind, MariaDB) ausrollt, ist mit SELinux schneller compliance-fertig, weil die mitgelieferten Policies den Großteil abdecken. Eine wichtige Beobachtung aus meinen letzten Projekten: Die Halbwertszeit eines selbst geschriebenen AppArmor-Profils ist in der Regel länger als die einer eigenen SELinux-Policy, weil pfadbasierte Regeln seltener von Upstream-Updates gebrochen werden als labelbasierte Module nach Paketwechseln.

Können SELinux und AppArmor gleichzeitig laufen?

Seit Kernel 5.1 unterstützt der LSM-Stack mehrere „minor" Module gleichzeitig, aber SELinux und AppArmor sind beide „major" Module und schließen sich pro Hook gegenseitig aus. In der Praxis aktivieren Sie eins. Der Kernel-Bootparameter lsm=lockdown,yama,integrity,apparmor oder analog mit selinux legt die Reihenfolge fest. Wer beide testet, sollte das auf getrennten VMs tun: ein hybrider Betrieb auf demselben System wird nicht unterstützt und führt zu unvorhersehbaren Denials.

Was Sie aber sehr wohl kombinieren können: Eines der beiden mit eBPF-basierten LSMs wie bpf oder Tetragon. Für 2026 zeichnet sich ab, dass produktive Stacks mit einem klassischen MAC-Framework (SELinux ODER AppArmor) plus einem eBPF-Layer für Runtime-Observability arbeiten. Das ist die belastbarste Kombination, die ich derzeit empfehle.

Wer migrieren will (etwa von AppArmor zu SELinux auf umgestellten Hosts), sollte zwei Wochen Permissive-Modus einplanen, die AVC-Logs mit ausearch und audit2allow -M auswerten und erst dann auf Enforcing wechseln. Eine harte Umstellung ohne Lernphase erzeugt typischerweise Dutzende stiller Denials, die in Logs verschwinden und Wochen später als „mysteriöser Fehler" zurückkommen. Dokumentieren Sie jedes selbst geschriebene Modul in Ihrem Konfigurationsmanagement, inklusive einer kurzen Begründung. Das spart in jedem Compliance-Audit Tage an Nachfragen.

Häufig gestellte Fragen

Wie aktiviere ich SELinux unter Ubuntu?

Ubuntu setzt standardmäßig auf AppArmor, SELinux ist aber installierbar: sudo apt install selinux-basics selinux-policy-default auditd, dann selinux-activate ausführen und neu starten. Beachten Sie, dass die meisten Ubuntu-Pakete keine SELinux-Kontexte mitliefern, Sie werden viele eigene Policies schreiben müssen.

Wie deaktiviere ich AppArmor temporär?

Einzelne Profile setzen Sie mit sudo aa-complain /etc/apparmor.d/<profil> in den Lernmodus oder mit sudo aa-disable komplett aus. Den Service stoppen Sie mit sudo systemctl stop apparmor, eine dauerhafte Deaktivierung ist über den Kernel-Bootparameter apparmor=0 möglich, wird aber für Produktionssysteme nicht empfohlen.

Verlangsamt SELinux den Server merklich?

Auf modernen Kerneln liegt der Overhead bei 2–7 % für syscall-intensive Workloads und unter 1 % für CPU- oder netzwerkgebundene Lasten. Optimierte Policies und das Vermeiden von setroubleshoot in Produktion halten den Effekt klein. Bei extrem latenzkritischen Datenbanken kann ein gezieltes Profiling der Booleans nochmal 1–2 % bringen.

Welche MAC-Lösung verwendet Kubernetes 2026?

OpenShift und CRI-O nutzen SELinux mit MCS-Isolation pro Pod. Vanilla-Kubernetes auf Ubuntu-Knoten greift typischerweise auf AppArmor zurück; seit Kubernetes 1.30 ist appArmorProfile ein stabiles Feld in der Pod-Security-Spec. Beide Optionen sind produktionstauglich, die Wahl hängt vom Node-OS ab.

Reicht MAC allein als Härtungsmaßnahme?

Nein. MAC ist eine wichtige, aber nicht die einzige Schicht. Eine vollständige Härtung umfasst Kernel-Lockdown, signierte Boot-Chain, restriktive Netzwerk-Policies, regelmäßiges Patchen, Audit-Logging und idealerweise eine eBPF-basierte Runtime-Detection. MAC reduziert den Schaden, wenn andere Schichten versagen. Sie ersetzt keine dieser Schichten.