SELinux vs. AppArmor: Vergleich für Linux-Server
15 Min. Lesezeit - 21. Mai 2026

Vergleich von SELinux und AppArmor für die Sicherheit von Linux-Servern: Erfahren Sie, wie die beiden MAC-Frameworks funktionieren, welche Unterschiede bestehen und welche Sie für Ihr Hosting-Setup wählen sollten.
SELinux vs. AppArmor: Welches MAC-Framework passt zu Ihrem Server?
SELinux und AppArmor setzen beide Mandatory Access Control (MAC) unter Linux durch und schränken die Möglichkeiten von Prozessen ein, selbst wenn diese Root-Rechte erlangen. Der Unterschied liegt darin, wie sie dies tun. SELinux weist jeder Datei und jedem Prozess persistente Labels zu. AppArmor verwendet stattdessen Dateipfadregeln. Diese eine Designentscheidung bestimmt alles andere: Komplexität, Sicherheitstiefe und welche Distribution welches Tool standardmäßig mitliefert.
So funktioniert SELinux
SELinux wurde ursprünglich von der NSA entwickelt und ist standardmäßig in RHEL, CentOS, Fedora und Rocky Linux enthalten. Es kennzeichnet jedes Objekt im System, einschließlich Dateien, Prozesse, Ports und Sockets, mit einem Sicherheitskontext im Format user:role:type:level. Das type Feld übernimmt den Großteil der Arbeit über einen Mechanismus namens Type Enforcement (TE).
Beispielsweise läuft der Apache-Webserver als httpd_t. Webinhaltsdateien tragen einen anderen Typ. Wenn keine Richtlinienregel den Zugriff auf diesen Inhaltstyp ausdrücklich erlaubt httpd_t den Zugriff auf diesen Inhaltstyp nicht ausdrücklich erlaubt, wird die Anfrage abgelehnt. Dies ist ein „Deny-by-Default“-Modell. Nichts ist erlaubt, es sei denn, eine Regel besagt etwas anderes.
SELinux unterstützt zudem Multi-Level Security (MLS) und Multi-Category Security (MCS), die Daten nach Vertraulichkeitsstufen klassifizieren und den Zugriff entsprechend einschränken. MCS verleiht SELinux seine starke Container-Isolation, indem es Container voneinander und vom Host trennt. Dies ist in Kubernetes- und OpenShift-Umgebungen von Bedeutung, in denen sich Pods einen Knoten teilen.
Der Nachteil ist die Komplexität. SELinux hat eine steile Lernkurve. Die Fehlerbehebung bei Zugriffsverweigerungen erfordert das Lesen von Audit-Protokollen, das Verstehen von Sicherheitskontexten und manchmal das Erstellen benutzerdefinierter Richtlinienmodule mit audit2allow. Für Teams ohne dediziertes Sicherheitspersonal ist dieser Aufwand erheblich.
So funktioniert AppArmor
AppArmor verfolgt einen anderen Ansatz. Anstatt Objekte zu kennzeichnen, ordnet es Anwendungen Sicherheitsprofile zu, die auf deren Dateipfaden basieren. Ein Profil für /usr/sbin/nginx legt fest, welche Verzeichnisse Nginx lesen darf, an welche Ports es sich binden darf und welche Funktionen es benötigt. Profile sind reine Textdateien, die in /etc/apparmor.d/.
AppArmor ist das Standard-MAC-Framework unter Ubuntu, Debian und SUSE. Es ist seit Version 2.6.36 Teil des Linux-Kernels. Anwendungen ohne Profil greifen auf die Standard-DAC-Berechtigungen von Linux zurück.
AppArmor läuft pro Profil in zwei Modi: „Enforce“ (blockiert und protokolliert Verstöße) und „Complain“ (protokolliert Verstöße, ohne zu blockieren). Dies ermöglicht die schrittweise Einführung neuer Profile. Beginnen Sie im „Complain“-Modus, überprüfen Sie die Protokolle, verschärfen Sie das Profil und wechseln Sie dann zu „Enforce“.
Tools wie aa-genprof und aa-logprof helfen dabei, Profile interaktiv zu erstellen, indem sie das Verhalten einer Anwendung beobachten und daraus Regeln generieren. Im Vergleich zu SELinux-Policy-Modulen ist die Syntax viel einfacher zu lesen und von Hand zu bearbeiten.
Der Nachteil ist, dass pfadbasierte Regeln Dateien nicht folgen, wenn diese verschoben werden. Ein Hardlink oder ein Bind-Mount kann theoretisch eine pfadbasierte Einschränkung umgehen. AppArmor bietet zudem keine native MLS/MCS-Unterstützung, sodass es Container zwar vom Host, aber nicht voneinander isolieren kann, wie es SELinux tut.
Direkter Vergleich
| Funktion | SELinux | AppArmor |
|---|---|---|
| Zugriffskontrollmodell | Label-basiert (Sicherheitskontexte) | Pfadbasiert (Dateisystem-Speicherorte) |
| Standardverhalten | Alles verweigern | Alles zulassen (Einschränkungen pro Profil) |
| Dateiverschiebung | Labels folgen der Datei | Sicherheit ist an den Pfad gebunden |
| MLS/MCS-Unterstützung | Ja | Nein |
| Container-Isolation | Container-zu-Container und Container-zu-Host | Nur Container-zu-Host |
| Richtlinienformat | Kompilierte Binärmodule | Für Menschen lesbare Textdateien |
| Standard-Distributionen | RHEL, Fedora, CentOS, Rocky Linux | Ubuntu, Debian, SUSE |
| Lernkurve | Steil | Mäßig |
Grundkonfiguration
SELinux
Überprüfen Sie den aktuellen Status:
sestatus
getenforceStarten Sie im Permissive-Modus, um Verstöße zu protokollieren, ohne etwas zu blockieren:
setenforce 0Verwenden Sie für die meisten Server die „targeted“-Richtlinie. Sie schränkt risikoreiche Dienste wie Webserver und Datenbanken ein, während alles andere uneingeschränkt bleibt. Machen Sie dies dauerhaft in /etc/selinux/config:
SELINUX=enforcing
SELINUXTYPE=targetedÜberprüfen Sie die Sicherheitskontexte von Dateien und Prozessen:
ls -Z /var/www/html
ps -eZ | grep httpdWenn ein Dienst einen nicht standardmäßigen Port verwendet, aktualisieren Sie die Richtlinie:
semanage port -a -t ssh_port_t -p tcp 9999Erstellen Sie für benutzerdefinierte Anwendungen, die Zugriffsverweigerungen generieren, ein Richtlinienmodul aus dem Audit-Protokoll:
ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.ppAppArmor
Überprüfen Sie, welche Profile geladen sind:
sudo aa-statusInstallieren Sie das Dienstprogramm-Paket, wenn Sie Tools zur Profilverwaltung benötigen:
sudo apt install apparmor-utilsErstellen Sie ein Profil interaktiv, während die Anwendung läuft:
sudo aa-genprof /path/to/binaryVerfeinern Sie das Profil, indem Sie die Protokolle auf Verstöße überprüfen:
sudo aa-logprofWechseln Sie zwischen den Modi eines Profils:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginxWelches sollten Sie verwenden?
Die praktische Antwort für die meisten Administratoren: Verwenden Sie das, was Ihre Distribution mitliefert. RHEL, CentOS, Fedora und Rocky Linux werden mit SELinux ausgeliefert. Ubuntu, Debian und SUSE werden mit AppArmor ausgeliefert. Beide Frameworks verfügen über ausgereifte Tools und Richtlinien für ihre jeweiligen nativen Plattformen. Ein Wechsel zur Nicht-Standard-Option bei einer Distribution bedeutet zusätzlichen Aufwand und verringert den Support durch die Community.
Darüber hinaus sollten Ihre Anforderungen den Ausschlag geben:
- Entscheiden Sie sich für SELinux, wenn Sie die Einhaltung von PCI DSS, HIPAA oder DISA-STIG benötigen. Wenn Sie Multi-Tenant-Container-Workloads auf Kubernetes oder OpenShift ausführen. Wenn Sie eine Isolation von Container zu Container auf gemeinsam genutzten Hosts benötigen. Wenn Ihre Umgebung klassifizierte oder nach Sensibilitätsstufen eingeteilte Daten verarbeitet.
- Wählen Sie AppArmor, wenn Sie Ubuntu oder Debian einsetzen und MAC-Schutz ohne großen Einarbeitungsaufwand wünschen. Wenn Ihre Umgebung aus einem einzelnen Server oder einem kleinen Cluster besteht, auf dem Standard-Webdienste laufen. Wenn eine schnelle Bereitstellung wichtiger ist als eine detaillierte Kontrolle auf Label-Ebene.
Beide Frameworks verursachen nur minimalen Laufzeit-Overhead. SELinux speichert Zugriffsentscheidungen in seinem Access Vector Cache. Das Laden der Richtlinien bei AppArmor kann beim Booten zu einer geringen Verzögerung führen, hat aber während der Laufzeit nur vernachlässigbare Auswirkungen. Bei den meisten Hosting-Workloads wird keines der beiden Systeme zum Engpass werden.
Wenn Sie eine zuverlässige Hosting-Basis mit vollständigem Root-Zugriff benötigen, um eines der beiden Frameworks zu konfigurieren, bieten Ihnen die dedizierten Server oder VPS von FDC die Kontrolle, SELinux oder AppArmor genau so einzurichten, wie es Ihre Umgebung erfordert.

Zombie-Prozesse in Linux: Finden, Entfernen, Verhindern
Lernen Sie, wie Sie Zombie-Prozesse in Linux identifizieren, entfernen und verhindern können. Befehle, Codekorrekturen und Überwachungstipps für Serveradministratoren.
15 Min. Lesezeit - 19. Mai 2026
Checkliste für die Härtung von Linux-Servern
15 Min. Lesezeit - 8. Mai 2026

Haben Sie Fragen oder benötigen Sie eine individuelle Lösung?
Flexible Optionen
Globale Reichweite
Sofortige Bereitstellung
Flexible Optionen
Globale Reichweite
Sofortige Bereitstellung