© Natallia Khlapushyna, 123RF

Mancher Admin schwört auf ihre zusätzliche Sicherheit, anderen sind SE Linux und App Armor ein Graus. Was verbirgt sich hinter den Lösungen und wie umgehen Admins die größten Klippen?

Keine Frage: Sicherheit ist wichtig – darauf können sich Admins meist schnell einigen. Darüber aber, was Sicherheit ist und wie sie sich erreichen lässt, gehen die Meinungen deutlich auseinander: Den einen genügt es, zum Beispiel durch Firewalls oder Packet Filter ihre Systeme so zu sichern, dass potenzielle Angreifer keinen Zugriff erhalten. Anderen geht das nicht mal im Ansatz weit genug: Sie wollen sicherstellen, dass auch legitime, lokale Nutzer unter Dauer-Beobachtung stehen und nur tun dürfen, was der Admin explizit erlaubt.

Entsprechend schwören etliche Admins auf App Armor und SE Linux. Deutlich größer aber ist die Gruppe derer, die unmittelbar nach der Linux-Installation diese Tools entweder deaktivieren oder gleich ganz deinstallieren. Major Hayden betreibt aus diesem Grund die Website http://www.stopdisablingselinux.com, die darauf hinweist, dass Dan Welsh – der Erfinder von SE Linux – jedes Mal eine Träne vergießt, wenn ein Admin auf seinem Linux-System SE Linux abschaltet. Dieser sicher nicht ganz ernst gemeinte Hinweis hat einen ernsten Hintergrund: Vielen Admins ist es schlicht zu mühsam, sich mit SE Linux auseinanderzusetzen und es zu verstehen.

Dieser Artikel will eine Lanze für SE Linux und App Armor brechen: Wie genau funktionieren die Lösungen eigentlich? Was unterscheidet sie, was haben sie gemeinsam und wie lassen sich alltägliche Probleme im Umgang mit ihnen lösen, ohne sie abzuschalten? Dazu geht es ganz am Anfang tief hinab in die Innereien des Linux-Kernels.

Gemeinsames Framework

Was vielen Admins gar nicht klar ist: Sowohl App Armor als auch SE Linux sind im Linux-Kernel an derselben Stelle verankert. Bereits seit 2003 gehören die Linux Security Modules (LSM) zum Linux-Kernel. Dabei handelt es sich um ein eigens für den Linux-Kernel verfasstes Security-Framework, das mit dem ausdrücklichen Ziel entwickelt worden ist, eine generische Schnittstelle für die so genannte Mandatory Access Control (MAC) zu sein.

Das ursprüngliche Prinzip, nach dem Linux den Zugriff auf bestimmte Kernelfunktionen und Dateien zulässt, ist bis heute ein anderes: Bei der Discretionary Access Control entscheidet der Kernel ausschließlich anhand der Identität des Benutzers, ob er den Zugriff auf die angefragte Funktion oder die angefragte Ressource erlaubt. Meist ist ein solches Rechtekonzept allerdings ziemlich simpel: Es gibt Root und es gibt Nutzer sowie Gruppen – anhand dieser legt Root, der alles darf, fest, wer Zugriff auf welche Ressourcen erhält.

Die Mandatory Access Control erweitert dieses Prinzip: Hier ist nicht mehr allein ausschlaggebend, wer der Nutzer ist. Es gelten zusätzliche Regeln, die entscheiden, ob ein Anwender Zugriff erhält oder nicht. Die LSM sind zu diesem Zweck zwischen dem Kernel und den Systemaufrufen verortet, die auf Posix-kompatiblen Betriebssystemen die Grundlage für jede Operation sind.

Entscheidet ein MAC-System anhand der bestehenden Regeln, dass ein Nutzer die angeforderte Aktion nicht ausführen darf, blockiert es schlicht den Systemaufruf. Der Anwender erhält dann lediglich eine – oft kaum aussagekräftige – Fehlermeldung. Das ist übrigens ein Grund dafür, dass SE Linux und App Armor bei Admins unbeliebt sind.

Wohlgemerkt: Ab Werk sind die LSM in Linux zwar aktiv, doch sind sie eben selbst kein MAC-System. Sie bieten lediglich die Schnittstelle für Lösungen wie App Armor und SE Linux an, werden von sich aus jedoch nicht tätig. Dazu ist eine konkrete MAC-Implementierung nötig, zum Beispiel Smack oder Tomoyo, die beide im Quelltext des Linux-Kernels integriert sind.

Die beiden großen Lösungen heißen jedoch zweifellos SE Linux und App Armor – sie gehören ebenfalls zu Linux. Aus welchem Grund gibt es eigentlich zwei große MAC-Systeme? Die Antwort lautet wie so oft: Weil sich zwei Hersteller in der Linux-Welt nicht einigen konnten.

SE Linux: Red Hats Schützling

SE Linux http://1 (Security Enhanced Linux) blickt unter der Ägide von Red Hat auf eine lange Geschichte zurück. Seit Linux 2.6 gehört es zum Linux-Kernel. Frühe Versionen von Fedora Core waren die ersten offiziellen Distributionen, die mit SE-Linux-Support daherkamen. Auch die NSA beteiligt sich maßgeblich an SE Linux und treibt dessen Entwicklung voran (Abbildung 1).

Abbildung 1: SE Linux basiert auf den Linux Security Modules und dockt direkt im Kernel an. Es fängt eingehende Systemaufrufe ab.

Obgleich SE Linux bereits einige Jahre auf dem Buckel hat, haben sich die grundlegenden Funktionsmechanismen der Lösung kaum geändert: Unter der SE-Linux-Haube werkelt ein einigermaßen komplexes System bestehend aus Rollen, Identitäten, Domains und darauf aufbauend von Kontexten. Grundsätzlich gehört SE Linux zur Riege der Type-Enforcement-Lösungen: Alle Objekte des Systems – also Ordner, Dateien, Geräte, Unix-Sockets und viele andere – sind einem Typ zugeordnet, etwa dem Typ »sshd_exec_t« im Beispiel des SSH-Daemon. Zu welchem Typ eine Datei gehört, steht in den erweiterten Attributen der Datei im Dateisystem, also in den Extended Attributes.

Das heißt im Umkehrschluss: SE Linux lässt sich nur mit Dateisystemen nutzen, die Extended Attributes unterstützen. Merken sollte der Admin sich jedenfalls, dass auf Systemen mit SE Linux die Zugriffskontrolle pro Datei und pro Nutzer erfolgt – ein wichtiger Unterschied zu App Armor, wie sich später noch herausstellen wird.

Eine Frage der Identität

Loggt sich ein Nutzer auf einem System mit aktiviertem SE Linux ein, hat er neben seinem Benutzernamen automatisch auch eine SE-Linux-Identität, etwa »user_u«. An der SE-Linux-Identität hängt automatisch eine Rolle, etwa »user_r«. Diese Rolle erlaubt es dem Nutzer lediglich, sich in einer Sicherheitsdomäne zu bewegen: »user_t«. Die SE-Linux-internen Domänen sind ebenfalls Typen, was den Appendix »_t« erklärt, wo doch eigentlich »_d« logisch wäre.

SE-Linux-Identität, Rolle und Domäne bedingen einander also – im SE-Linux-Sprech heißt dieses Konstrukt Default Security Context. SE Linux bietet die Möglichkeit, Nutzern das Ausführen mehrerer Rollen zu erlauben. Mit der Rolle ändert sich dann auch die Domäne. Alle Programme, die Nutzer in Systemen mit SE Linux starten, laufen innerhalb der Domäne, die zur Rolle gehört, die der Nutzer beim Zeitpunkt des Programmaufrufs innehatte.

Die Kopplung zwischen Objekten und den damit assoziierten Zugriffsrechten geschieht über die Domains. Jene legen nämlich durch ein komplexes Regelwerk fest, welche Arten von Operationen für welche Typen erlaubt sind. Ein simples Beispiel: Ist der Typ der Datei »/usr/sbin/sshd« auf »sshd_exec_t« festgelegt, verweigert SE Linux das Ausführen des Befehls, wenn in der Domain des aufrufenden Nutzers für den Typ »sshd_exec_t« die Ausführen-Operation nicht explizit erlaubt ist.

Bäumchen wechsle dich

Klar ist: Bei Zehntausenden von Objekten auf einem System kommt eine große Anzahl verschiedener Typen zusammen. Und als ob dieses vermeintliche Chaos nicht schon groß genug wäre, trägt ein weiterer Faktor zur Verwirrung bei: Es ist in SE Linux technisch möglich und durch Red Hat auch eindeutig vorgegeben, dass Programme im laufenden Betrieb ihre Security Domain wechseln können. Das Beispiel SSHd macht das deutlich: Systemd läuft in einer »init_t«-Domäne, SSHd selbst später jedoch in der Domäne »sshd_t«. Wann welche Wechsel in welche Domain vorgegeben sind, legt das SE-Linux-Regelwerk penibel fest.

Das beschriebene Prinzip macht auch deutlich, warum viele Admins einen großen Groll auf SE Linux hegen: Selbst wenn ein Benutzer Mitglied der richtigen Gruppen ist und die Zugriffsrechte einer Datei, eines Ordners oder eines Sockets auf Unix-Ebene passen, bekommt der Nutzer beim Zugriff auf jenes Objekt möglicherweise trotzdem einen Permission-Denied-Fehler.

Noch blöder ist es, wenn nicht menschliche Nutzer von einem Problem betroffen sind, sondern Programme: Das PAM-Modul »pam_mkhomedir« etwa, das auf Systemen mit einer LDAP-Benutzeranbindung die Homeverzeichnisse für neue User anlegen soll, lässt sich auf einer Centos-Standardinstallation nicht nutzen. Denn SE Linux im Kernel untersagt ganz einfach den schreibenden Zugriff auf »/home« für die Domäne, aus der heraus der Befehl ausgeführt wird.

Vieles ganz anders: App Armor

Die zweite MAC-Lösung für Linux, die es zu großer Verbreitung gebracht hat, App Armor http://2, unterscheidet sich deutlich von SE Linux. Viele Anwender verbinden mit App Armor automatisch Canonical, weil Ubuntu an der App-Armor-Entwicklung seit Jahren beteiligt ist. Tatsächlich hat jedoch Suse App Armor erfunden, offiziell natürlich ausschließlich aus technischen Gründen. Kritiker führen etwa die hohe Komplexität von SE Linux an. Nicht ganz unwahrscheinlich ist es allerdings auch, dass man in Nürnberg ein Interesse daran hatte, eine Alternative zu der Lösung des großen Konkurrenten am Markt zu etablieren – “Not Invented Here” lässt grüßen.

Einerseits gibt es zwischen App Armor und SE Linux manche Gemeinsamkeit. So basiert auch App Armor auf den Linux Security Modules, dockt im Linux-Kernel also an derselben Stelle an wie die Konkurrenz (Abbildung 2). App Armor ist damit ganz automatisch auch ein System zur Umsetzung von Mandatory Access Control. Und: Auch App Armor unterscheidet für jede einzelne Datei, ob der erbetene Zugriff erlaubt ist oder nicht – wenn auch auf weniger komplexe Art und Weise. Viel mehr verbindet die beiden Lösungen aber nicht.

Abbildung 2: Auch App Armor dockt bei den Linux Security Modules an und fängt Systemaufrufe ab.

Das wird etwa bei der Frage deutlich, wie App Armor die Entscheidung trifft, eine bestimmte Art der Zugriffs zu erlauben oder zu verbieten. Denn dabei spielen Informationen über den Benutzer, der zugreifen möchte, keine Rolle. Das Prinzip des Sicherheitskontextes ist App Armor genauso fremd wie überhaupt Rollen oder Domains, die den Zugriff steuern. Ganz gleich welcher Benutzer den Zugriff auf ein bestimmtes Objekt anfragt – er hat aus Sicht von App Armor exakt die gleichen Rechte wie alle anderen Benutzer auch.

Ebenso wenig stellt App Armor besondere Bedingungen an das Dateisystem, denn Extended Attributes verwendet die Lösung nicht. Was im Alltag ein Vorteil sein kann: Nicht alle bestehenden Dateisysteme unterstützen Extended Attributes, NFS ist ein prominentes Beispiel dafür. Dort lässt sich SE Linux nicht verwenden – App Armor dagegen schon.

Programm-basierte Tests

Das einzige Kriterium, das für App Armor überhaupt eine Rolle bei der Entscheidung spielt, ob es den Zugriff auf ein Objekt erlaubt, ist dessen Pfad im System. Die Regeln für dieses Spiel sind in so genannten Profiles definiert: Ein App-Armor-Profil legt die Zugriffsregeln für Programme im System fest.

Ein App-Armor-Profil für den Daemon »sshd« könnte zum Beispiel festlegen, dass dieses Programm auf die Datei »/etc/ssh/sshd_config« lesend zugreifen darf. Führt Systemd das Programm »sshd« dann beim Systemstart tatsächlich aus, überprüft App Armor, das seit Linux 2.6.36 in den Linux-Kernel integriert ist, dessen Systemaufrufe und winkt sie durch oder blockiert sie, wenn der Daemon auf Ressourcen zugreifen will, die ihm nicht erlaubt wurden.

Die Profildateien liegen im Klartext-Format alle im Verzeichnis »/etc/ apparmor.d«. Dort liest ein Hilfsprogramm sie aus und lädt sie beim Start des Systems in den laufenden Kernel. Das hat aus Sicht des Nutzers den Vorteil, dass es sehr einfach ist, zusätzliche App-Armor-Profile hinzuzufügen. Tatsächlich genügt es, ein syntaktisch korrektes File in den genannten Ordner zu platzieren und anschließend den Befehl »aa-enforce Programm« als Benutzer Root auf der Kommandozeile aufzurufen. »Programm« ist dabei durch den Namen des Programms zu ersetzen, auf den sich das App-Armor-Profil beziehen soll.

Und das war es dann auch schon: Ab sofort schaut App Armor dem genannten Binary genau auf die Finger. Von den von SE Linux her bekannten umständlichen und kraftraubenden Klimmzügen ist man bei App Armor weit entfernt.

Pfade statt Inodes

Ein weiterer Unterschied unter der Haube zwischen SE Linux und App Armor ist noch von zentraler Bedeutung: Für das Referenzieren von Dateien im Dateisystem benutzt App Armor ausschließlich den Pfad. SE Linux hingegen orientiert sich an dem Dateisystem-Inode. Das hat Konsequenzen: Durch gezieltes Setzen von Hardlinks ließe sich App Armor schlimmstenfalls austricksen, weil dann über einen anderen Pfad zugegriffen würde als den, der im App-Armor-Profil beschrieben ist.

SE Linux hat dieses Problem nicht: Der Inode eines Hardlinks ist schließlich mit jenem der Originaldatei identisch. In der Praxis dürfte das Problem aber trotzdem von untergeordneter Bedeutung sein, denn wer als Root auf einem System gefährliche Hardlinks anlegen darf, der hat die Hürden des MAC-Systems ohnehin schon überwunden.

Mit SE Linux arbeiten

Die grundlegende Einführung macht deutlich: Mandatory Access Control sorgt für zusätzliche Hürden gemessen am klassischen Unix-Rechteschema. Sehr zum Leidwesen manches Admin: Oft kommt es vor, dass er viel Zeit mit Fehlersuche für einen seltsamen Effekt vergeudet, weil ihm SE Linux oder sein Konkurrent App Armor als potenzielle Missetäter gar nicht einfallen.

Stößt der Admin dann auf verräterische Einträge in »/var/log/audit/audit.log« (bei SE Linux) oder »/var/log/dmesg« (bei App Armor), ist der erste Reflex oft das komplette Deaktivieren der MAC aus lauter Wut. Doch das sollte nicht sein: Mit ein paar Handgriffen und Wissen über die grundlegenden Werkzeuge lassen sich gute Ergebnisse erzielen – und zwar ohne die zusätzlichen Zugriffskontrollen komplett abzuschalten. Im Fokus steht zunächst SE Linux.

Herausfinden, was los ist

Ist er einem Berechtigungsproblem auf einem System auf der Spur, sollte der Admin zunächst herausfinden, ob SE Linux als Schuldiger überhaupt in Frage kommt. Auf RHEL, Centos und den Derivaten dieser Distributionen ist SE Linux ab Werk nicht nur aktiviert, sondern es ist auch scharf geschaltet, also im Enforcing-Modus. Ob das für das aktuelle System zutrifft, lässt sich durch den Aufruf von »sestatus« leicht herausfinden. Neben »enforcing« kennt SE Linux auch den »permissive«-Modus, bei dem es zwar Rechteverstöße bemängelt, sie aber nicht unterbindet.

Ist SE Linux auf dem System aktiv und damit potenziell verdächtig, folgt im nächsten Schritt ein Blick auf »/var/log/audit/audit.log«. Für jeden Verstoß, den SE Linux auf der Kernelebene unterbindet, findet sich in dieser Datei ein eigener Log-Eintrag. Im Falle des Beispiels »pam_mkhomedir« würde etwa ein »grep mkhomedir /var/log/audit/audit.log« zu aufschlussreichen und weiterführenden Informationen verhelfen.

Wenn klar ist, dass SE Linux das Problem ist, geht die Forschung weiter: Die Zeile aus dem Audit-Log enthält detaillierte Informationen darüber, warum SE Linux den Zugriff unterbunden hat – allerdings in einem schwierig zu verstehenden Format. Hier hilft das Werkzeug »seaelert«: Der Aufruf von »sealert -a /var/log/audit/audit.log > /root/audit.log« wandelt die Ausgabe des Werkzeugs in ein besser lesbares Format um.

Wer die Angaben im Audit-Log danach verifizieren möchte, braucht bei vielen Konsolenwerkzeugen den Parameter »-Z«: Ein »ls -Z« auf eine Datei zeigt etwa an, welche SE-Linux-Zugriffsregeln für diese Datei gelten. Ein »ps -Z« gibt einen umfassenden Überblick über die Sicherheitskontexte der verschiedenen, auf dem System laufenden Programme. Ohne »-Z« kommt »id« aus: Auf Systemen mit aktivem SE Linux zeigt das auf jeden Fall den aktuellen Sicherheitskontext des Nutzers mit der fraglichen ID an.

Das Problem lösen

Wie es weitergeht, entscheidet der Admin: Er kann wahlweise sein Setup so umbauen, dass es zu den SE-Linux-Anforderungen passt, etwa indem er auf andere Komponenten zurückgreift. Oder er ändert die Berechtigungen der Dateien im System oder passt die geltenden SE-Linux-Richtlinien an. Die Berechtigungen von Objekten verändert der Admin dabei mit »chcon«. So würde der Befehl

chcon -v --type=httpd_sys_content_t /var/www/index.html

den Typ der Datei »/var/www/index.html« auf »httpd_sys_content_t« ändern – ein Apache, der in seinem Sicherheitskontext Zugriff auf diesen Typ hat, könnte anschließend auf die Datei zugreifen. Soll die Änderung dauerhaft sein, hilft der Befehl:

semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"

Das Anpassen der lokalen Policy-Module von SE Linux lässt sich zudem mit dem Werkzeug »audit2allow« noch deutlich bequemer gestalten. Erneut kommt dabei das Audit-Log ins Spiel: Der Befehl

grep html /var/log/audit/audit.log | audit2allow -m apachelocal > apachelocal.te

durchforstet das Audit-Log nach »html«, bevor »audit2allow« die Ausgabe auf zurückgewiesene Zugriffsversuche hin untersucht. Wird es fündig, schreibt es die Änderungen, damit der Zugriff klappt, im Klartext in die Datei »apachelocal.te« (Abbildung 3 – Beispiel für die Kombination Postfix und Postgrey).

Abbildung 3: Diese lokale SE-Linux-Policy erlaubt Postfix den Zugriff auf den Postgrey-Socket.

Der Zwischenschritt dient nur dazu, es dem Admin zu ermöglichen, den Inhalt von »apachelocal.te« zu überprüfen. Möchte er auf Basis des Inhalts wirklich die SE-Linux-Policies verändern, dann erstellt

grep html /var/log/audit/audit.log | audit2allow -M apachelocal

eine entsprechende SE-Linux-Policy in einem für SE Linux nutzbaren Format in »apachelocal.te«. Die muss der Admin dann noch scharf schalten – »semodule -i apachelocal.pp« tut das.

Das Centos-Projekt stellt in seinem Wiki übrigens eine gute Übersicht über die wichtigsten SE-Linux-Befehle zusammen und erklärt, wie sich typische Fehler erkennen und beheben lassen [3].

App Armor debuggen

Treten auf Ubuntu- oder Suse-Systemen unvorhergesehene Nebeneffekte auf, ist möglicherweise App Armor verantwortlich. Ob auf einem System App Armor überhaupt aktiv ist, findet der Admin mittels »aa-status« als Root schnell heraus (Abbildung 4). Falls das der Fall ist, hilft der Befehl »dmesg«, denn App Armor hinterlegt im Kernel-Log für jeden unterbundenen Zugriff eine entsprechende Meldung. Anders als bei SE Linux sind diese Meldungen auch ohne besondere Werkzeuge lesbar, weil sie in einem verständlichen Format erscheinen.

Abbildung 4: Der Befehl »aa-status« listet auf, welche App-Armor-Profile aktiv sind.

Da der gesamte App-Armor-Unterbau deutlich weniger komplex ist als der von SE Linux, ist auch das Anpassen der geltenden Regeln einfacher. Mit den Berechtigungen von Dateien oder Ordnern im Dateisystem schlägt sich der Admin erst gar nicht herum, denn die haben ohnehin keinen Einfluss auf die von App Armor getroffenen Entscheidungen. Besondere Parameter für »ls«, »ps« oder andere Werkzeuge sind also unnötig.

Stattdessen gestaltet sich der gesamte Prozess recht simpel: Damit App Armor überhaupt Zugriff durch ein bestimmtes Programm unterbindet, muss für dieses ein Profil aktiv sein, das obendrein im »enforce«-Modus ist. Denn Profile im »complain«-Modus führen zwar zur Anzeige einer Warnmeldung in »dmesg«, aber App Armor unterbindet den Zugriff nicht. Schlägt der Zugriff durch ein Programm auf ein Objekt im Dateisystem also fehl, ist klar, dass für das jeweilige Programm ein App-Armor-Profil im »enforce«-Modus aktiv ist.

Alle App-Armor-Profile liegen in »/etc/apparmor.d«. Die Namensgebung ist bei Suse und Ubuntu eindeutig, alternativ kann man auch in den dort hinterlegten Dateien per »grep« nach dem Programm suchen, das durch App Armor blockiert worden ist. Ist das passende Profil identifiziert, macht sich der Admin daran, es zu bearbeiten (Abbildung 5).

Abbildung 5: Das »cupsd«-Profil von Ubuntu 17.04 listet die Regeln in App Armor auf, denen Cups unterworfen ist.

App-Armor-Profile verstehen

Ein App-Armor-Profil unterteilt sich in verschiedene Teile: Ganz oben kann der Admin per »#include«-Direktive Verweise auf andere Profile angeben. Darunter sind die »capabilities« definiert, die das Programm im Kernel nutzen darf. Danach kommen die Zugriffsrechte auf Objekte samt dem erlaubten Modus, also lesend, schreibend oder kombiniert. Das Ubuntu-Wiki hält ein simples Beispiel für »tcpdump« parat [4].

Hat der Admin das Profil nach den eigenen Wünschen angepasst, lädt er es neu: »apparmor_parser -r /etc/apparmor.d/« erledigt das. Unterm Strich kommt man mit App Armor also leichter zurecht als mit SE Linux.

Fazit: MAC ist nützlich

SE Linux und App Armor sind beide erprobte Sicherheitsmechanismen. Es gibt gute Gründe dafür, dass SE Linux bei Red Hat, Centos & Co., aber App Armor bei Ubuntu und Suse zur Grundausstattung neuer Systeme gehören.

Beide Ansätze unterscheiden sich deutlich: SE Linux ist viel mächtiger, aber zum Preis von höherer Komplexität und schwierigerer Bedienung. App Armor lässt sich auch mit wenig Vorarbeit gut verwenden, bietet jedoch weniger Stellschrauben als SE Linux und sichert die Systeme nicht so umfassend gegen Angriffe von innen ab wie jenes.

Es gilt: Statt die MAC nach einem fehlgeschlagenen Objekt-Zugriff abzuschalten, sollte der Admin sich lieber die Mühe machen und zu verstehen lernen, wie SE Linux oder App Armor funktionieren. Das freut dann nicht nur die Compliance-Abteilung, sondern sorgt auch für ein Plus bei der Sicherheit.