AppArmor oder SELinux: Welches MAC-System für Linux wählen?

Wenn Sie ein Linux-System härten, stehen Sie früher oder später an einer Weggabelung: AppArmor oder SELinux. Beide sind Mandatory-Access-Control-Systeme (MAC), die über dasselbe LSM-Framework (Linux Security Modules) in den Linux-Kernel integriert sind. Beide schließen einen kompromittierten Prozess so ein, dass ein Exploit nicht ungehindert auf den Rest Ihres Systems zugreifen kann. Doch sie verfolgen sehr unterschiedliche Ansätze, und die richtige Wahl hängt weniger davon ab, welches „mächtiger” ist, als davon, was Sie betreiben, welche Distribution Sie nutzen und wie viel Aufwand für Richtlinien Sie zu investieren bereit sind.

Dieser Leitfaden vergleicht beide nach Konzept, nach täglichem Wartungsaufwand und nach Bedrohungsmodell – damit Sie entscheiden, statt zu raten.

Was Mandatory Access Control tatsächlich leistet

Klassische Linux-Berechtigungen sind diskretionär: Der Eigentümer einer Datei entscheidet, wer sie lesen oder schreiben darf, und ein Prozess läuft mit allen Rechten des Benutzers, der ihn gestartet hat. Wird dieser Prozess ausgenutzt, erbt der Angreifer diese Rechte – Ihre Dateien, Ihr Netzwerk, Ihr Home-Verzeichnis.

Mandatory Access Control fügt eine zweite Schicht hinzu, die der Benutzer nicht aushebeln kann. Eine zentrale, vom Kernel durchgesetzte Richtlinie legt fest, was jeder Prozess tun darf – unabhängig vom Dateieigentümer. Einem durch MAC eingeschränkten Webserver kann vorgeschrieben werden, dass er nur sein eigenes Document-Root lesen und auf Port 443 lauschen darf; selbst wenn ein Angreifer ihn übernimmt, verweigert der Kernel weiterhin alles außerhalb dieser Hülle.

AppArmor und SELinux leisten beide genau das. Der Unterschied liegt darin, wie sie bestimmen, worauf ein Prozess zugreifen darf.

Der grundlegende Konzeptunterschied: Pfade gegen Labels

Diese eine Unterscheidung erklärt fast jeden praktischen Kompromiss zwischen beiden.

AppArmor arbeitet pfadbasiert. Ein Profil benennt die tatsächlichen Dateipfade, auf die ein Programm zugreifen darf. Eine Regel wie /etc/nginx/** r bedeutet „nginx darf alles unter /etc/nginx lesen”. Das deckt sich unmittelbar damit, wie Administratoren ohnehin über ein System denken, was Profile gut lesbar und schnell zu schreiben macht.

SELinux arbeitet labelbasiert. Jede Datei, jeder Prozess, jeder Socket und jeder Port trägt einen Sicherheitskontext (ein Label) wie httpd_sys_content_t. Die Regeln beschreiben, welche Labels miteinander interagieren dürfen – nicht welche Pfade. Der Pfad /var/www/html/index.html ist für SELinux irrelevant; entscheidend ist das daran angeheftete Label.

Die Folge: Verschieben Sie eine Datei unter AppArmor, gilt die Regel weiterhin, solange der neue Pfad abgedeckt ist. Unter SELinux kann eine verschobene Datei ihr Label behalten oder verlieren – je nach Methode (cp und mv verhalten sich unterschiedlich), die häufigste Verwirrungsquelle der Art „es funktionierte, bis ich die Datei kopiert habe”. Im Gegenzug ist eine labelbasierte Richtlinie schwerer auszutricksen: Ein Angreifer kann eine Regel nicht umgehen, indem er dieselben Daten über einen Symlink oder einen anderen Pfad erreicht, denn das Label wandert mit dem Objekt mit.

Granularität und Sicherheitsniveau

SELinux ist das feinkörnigere der beiden. Da jedes Objekt ein Label trägt, kann die Richtlinie Kontrollen ausdrücken, die AppArmor nicht erreicht – mehrstufige Sicherheit, Typdurchsetzung über Hunderte von Domänen und Einschränkungen, die etwa zwei Webanwendungen trennen, die beide unter /var/www liegen, aber niemals die Daten der jeweils anderen lesen sollten. Deshalb ist SELinux in Umgebungen mit formalen Sicherheitsanforderungen Standard (RHEL, Fedora, behördennahe Bereitstellungen) und wurde ursprünglich mit der US-amerikanischen National Security Agency entwickelt.

AppArmor ist bewusst gröber. Es kann nicht alles ausdrücken, was SELinux kann, doch für das übliche Ziel – einige netzexponierte Dienste und Browser so einzuschließen, dass ein einzelner Exploit nicht weiterspringen kann – spielt diese Obergrenze selten eine Rolle. Die meisten Desktop- und Kleinserver-Bedrohungsmodelle werden von der Ausdruckskraft von AppArmor vollständig abgedeckt.

Eine treffende Formulierung: SELinux bietet eine höhere Obergrenze; AppArmor bietet eine niedrigere Aufwandsuntergrenze. Welches gewinnt, hängt ganz davon ab, ob Sie diese Obergrenze tatsächlich brauchen.

Der Wartungsaufwand in der Praxis

Hier entscheidet sich die Wahl meist.

Bei AppArmor sind Profile kurze Textdateien, die Sie von Hand lesen und bearbeiten können. Distributionen, die es standardmäßig einsetzen (Ubuntu, Debian, openSUSE), liefern vorgefertigte Profile mit, und neue lassen sich interaktiv erzeugen:

# Geladene Profile und ihren Modus anzeigen
sudo aa-status

# Ein Profil für eine Anwendung erzeugen, indem man sie beim Laufen beobachtet
sudo aa-genprof /usr/bin/myapp

# Ein Profil in den Erzwingungsmodus versetzen
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

Ein „Complain”-Modus protokolliert Verstöße, ohne sie zu blockieren, sodass man ein Profil auf einem laufenden System entwickeln und nachschärfen kann, sobald der legitime Bedarf der Anwendung bekannt ist.

Bei SELinux ist die Richtlinie umfangreich, und man schreibt sie fast nie von Grund auf neu – man passt Boolesche Werte an und vergibt Labels neu. Der Reibungspunkt ist das Diagnostizieren von Verweigerungen. Der falsche Reflex ist setenforce 0, um es abzuschalten; der richtige ist, das Audit-Log zu lesen:

# Aktuellen Modus prüfen
getenforce

# Jüngste Verweigerungen prüfen und eine vorgeschlagene Richtlinie erhalten
sudo ausearch -m avc -ts recent | audit2allow -a

# Korrekte Labels auf einem Pfad wiederherstellen
sudo restorecon -Rv /var/www/html

audit2allow schlägt ein Richtlinienmodul vor, das die verweigerte Aktion erlauben würde; Sie prüfen es vor der Anwendung, um zu verstehen, warum die Verweigerung auftrat, statt pauschal zu erlauben. Dieser Ablauf ist mächtig, hat aber eine echte Lernkurve und ist der Hauptgrund, warum Administratoren SELinux abschalten, statt es zu erlernen – was den Schutz vollständig beseitigt.

Folgen Sie der Voreinstellung Ihrer Distribution

In der Praxis ist die solideste Empfehlung zugleich die einfachste: Nutzen Sie das MAC-System, das Ihre Distribution mitliefert und pflegt.

Gegen die Voreinstellung zu arbeiten bedeutet, eine nicht unterstützte Konfiguration zu betreiben: AppArmor-Profile für die Pakete von Fedora werden nicht gepflegt, und die SELinux-Richtlinie für das Paketlayout von Ubuntu ist unvollständig. Sie erben einen Wartungsaufwand, bei dem Ihnen die Distribution nicht hilft. Auf einer Fedora- oder RHEL-Maschine lassen Sie SELinux im Enforcing-Modus und lernen audit2allow. Unter Ubuntu oder Debian halten Sie AppArmor aktiviert und sorgen dafür, dass Browser und Netzwerkdienste mit Profilen im Erzwingungsmodus laufen.

Es ist dasselbe Prinzip wie bei der Wahl einer sicheren Linux-Distribution überhaupt: Der tatsächlich gepflegte Schutz schlägt den theoretisch stärkeren, aber auf Ihrem System nicht unterstützten.

Wo MAC in einer mehrschichtigen Verteidigung steht

Weder AppArmor noch SELinux ist eine vollständige Sicherheitsstrategie. MAC schließt bereits laufende Prozesse ein; es bewirkt nichts gegen nicht vertrauenswürdigen Code, den Sie bewusst ausführen, und nichts für die Isolation ganzer Arbeitslasten voneinander. Für die Isolation einzelner Desktop-Anwendungen arbeiten Sandboxing-Werkzeuge wie Firejail und bubblewrap neben MAC, nicht an seiner Stelle. Für die breitere Systemhärtung – Kernel-Parameter, sysctl, verifizierter Boot – ist MAC nur eine Schicht im größeren Bild der Linux-Härtung und fügt sich in den umfassenderen Vergleich der Modelle von Linux- gegen Windows-Sicherheit ein.

Das Fazit: Die Frage AppArmor-oder-SELinux ist real, aber eng begrenzt. Wählen Sie das, was Ihre Distribution pflegt, lassen Sie es im Erzwingungsmodus, und stecken Sie Ihren restlichen Aufwand in die Schichten darüber und darunter.

Häufig gestellte Fragen

Ist SELinux sicherer als AppArmor? SELinux kann eine strengere und feinere Richtlinie ausdrücken, in absoluten Zahlen ist seine Obergrenze also höher. Sicherheit entsteht jedoch aus einer Richtlinie, die tatsächlich durchgesetzt und gepflegt wird. Ein im Erzwingungsmodus belassenes AppArmor-System schützt Sie mehr als ein SELinux-System, das jemand abgeschaltet hat, weil die Verweigerungen verwirrten.

Kann ich beide gleichzeitig betreiben? Nein. AppArmor und SELinux sind beide „große” LSMs, und der Kernel lädt nur eines als primäres MAC-System. Sie wählen eines pro Maschine – in der Praxis das, was Ihre Distribution voreinstellt.

Sollte man sie jemals abschalten? Fast nie. MAC abzuschalten entfernt eine Schicht, die den Schadensradius eines kompromittierten Dienstes begrenzt. Bei einer Verweigerung diagnostizieren Sie diese (audit2allow bei SELinux, Complain-Modus bei AppArmor), statt das ganze System abzuschalten.

Was ist für Einsteiger einfacher? AppArmor. Seine pfadbasierten Profile lesen sich wie das Dateisystem, das Sie ohnehin verstehen, und Ubuntu und Debian liefern funktionierende Profile ab Werk. SELinux belohnt die investierte Lernzeit, aber diese Zeit ist real.