Probleme mit SELinux finden und lösen

chidsey , sxc.hu

Unter der Lupe

Verhindert der Einsatz von SELinux, dass ein Programm richtig funktioniert, wird oft geraten, die Zugriffskontrolle einfach abzuschalten. Für derart leichtsinnigen Aktionismus besteht aber kein Grund, denn Probleme in der Konfiguration lassen sich mit den folgenden Tipps schnell finden und beheben.
High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Tritt ein Fehler in der SELinux-Konfiguration eines Servers auf, fehlt vielen Admins oft die Zeit, dem eigentlichen Problem auf den Grund zu gehen. Kurzerhand lassen sie die Maschine ohne aktivierten SELinux-Schutz weiterlaufen und verschieben die Problemlösung auf später. Dieser Artikel zeigt, dass es auch anders geht: Mit dem nötigen Know-how und einigen kleinen Tricks läuft jede Anwendung auch mit aktivem Schutzschild.

Kurzer Rückblick

SELinux ist ein Security-Framework auf Basis der Mandatory Access Control, das Framework basiert auf dem Flask-Forschungsprojekt der amerikanischen NSA-Behörde [1]. Im Standardkernel ist es über das Linux-Security-Module-API (LSM) integriert. Alle Interaktionen zwischen so genannten Subjekten und Objekten sind durch eine gesonderte Security-Policy zu autorisieren.

Die Anweisungen enthalten dabei jedoch keine Datei-, Prozess- oder Benutzernamen, stattdessen kommt ein abstrahiertes Model mit Security-Labels zum Einsatz. Prozesse und Benutzer bekommen diese dynamisch zugewiesen, Dateien speichern das Label in den erweiterten Attributen. Es ist möglich, diese Policy zur Laufzeit des Systems zu ändern. Hierbei findet aber eine strikte Trennung von Policy und deren Durchsetzung statt.

Für das Enforcement sind diverse Hooks im Linux-Kernel zuständig. Sie erweitern die klassischen Zugriffsrechte der Discretionary Access Control (DAC) um die entsprechende MAC-Funktionalität. Über eine binäre Policy-Datei gelangen die eigentlichen Regelwerke in den Security-Server des Linux-Kernels.

SELinux kennt drei Modi: Im Enforcing-Mode ist jeder einzelne Zugriff einer Kontrolle durch die SELinux-Policy ausgesetzt. Jeder Zugriff wird ausgewertet und gegebenenfalls untersagt, wenn es keine Regel gibt, die diesen Zugriff erlaubt. Im Permissive Mode wird ebenfalls jeder Zugriff überwacht, allerdings kommt es nicht zur Durchsetzung der Regeln. Das bedeutet, dass ein Zugriff selbst dann stattfindet, wenn keine Regel den Zugriff explizit erlaubt.

SELinux schreibt für jeden nicht durch eine Regel erlaubten Zugriff einen Logeintrag, allerdings nur beim ersten Mal. Alle weiteren Zugriffe unterdrückt das System stillschweigend. Im Disabled Mode ist SELinux überhaupt nicht aktiv. Es kommen nur Zugriffsentscheidungen auf Basis der DAC zum Einsatz. Dabei muss der Administrator daran denken, dass Dateien, die im Disabled-Modus erzeugt wurden, auch kein Security-Label bekommen.

Type Enforcement

Zur Erweiterung des klassischen Discretionary-Access-Control-Modells stellt SELinux verschiedene Implementierungen zur Verfügung:

  • Type Enforcement (TE)
  • Role-based Access Control (RBAC)
  • Multi Level Security (MLS)
  • Multi Category Security (MCS)

Die wichtigste Implementierung ist hierbei das Type Enforcement. Es regelt den Zugriff von einem Subjekt, etwa einem Prozess, auf die diversen Objekte, beispielsweise Dateien oder Verzeichnisse. Allerdings gibt es eine Vielzahl unterschiedlicher Objekte. Zu diesen zählen neben Dateien und Verzeichnissen beispielsweise auch Netzwerkports. Die den Subjekten und Objekten zugewiesenen Security-Label sind auch unter dem Namen Domäne oder Typ bekannt. Allgemein ausgedrückt regelt das Type Enforcement, welche Domäne auf welchen Typ zugreifen darf.

Genau hier liegt oft das Problem. Besitzt ein Objekt nicht den richtigen Typ, ist der Zugriff darauf nicht möglich, wenn das System sich im SELinux-Enforcing-Modus befindet. Ein Logeintrag in der Datei »/var/log/audit/audit.log« sieht dann etwa wie in Listing 1 aus.

Listing 1

Zugriff verweigert

 

Der Logtyp bestimmt hierbei den Ursprung der Nachricht. AVC steht für Access Vector Cache und ist ein Teil des Security-Servers im Kernel, der Zugriffsvektoren zwischenspeichert. Der Logtyp »SYSCALL« bezieht sich beispielsweise auf Events, die das Audit-Subsystem festhält, wenn es um das Monitoring von Systemcalls geht. Mit Hilfe von »ausearch -m Typ« ist ein Zugriff auf einen ganz bestimmten Logtyp möglich.

Der nächste Eintrag gibt den Zeitpunkt des Events in Unix-Zeit an. Mit »date -d @Unix-Zeit« lässt sich diese leicht in ein von Menschen lesbares Format verwandeln. Im Anschluss erfolgt die genaue Art der Logmeldung, also ob es sich um eine Deny-Meldung handelt oder nur um eine Information, etwa ob die SELinux-Policy neu geladen wurde oder ob sich der SELinux-Modus geändert hat.

Die nächsten beiden Angaben (»pid« und »comm« ) bestimmen die Herkunft der Fehlermeldung, hier also einen Webserver-Prozess mit seiner Prozessnummer. Das Objekt der Begierde folgt unmittelbar in Form eines Dateipfads (»path« ), Device (»dev« ) und Inode-Nummer (»ino« ). Da für die Interaktion zwischen Prozess und Datei jedoch Security-Label die größte Bedeutung haben, sind diese natürlich ebenfalls aufgeführt. »scontext« steht hierbei für den Source-Context des Webservers, »tcontext« für den Target-Context der Datei. Zum Abschluss gibt die Logmeldung noch Auskunft über den genauen Objekt-Typ. Damit ist die Unterscheidung von Objekten mit gleichem Security-Label möglich.

Seit einiger Zeit gibt es für diese doch recht kryptischen Logeinträge eine Alternative. Fedora Core hat mit Version 6 den Setroubleshoot-Daemon [2] eingeführt. Bei dieser Gnome-Anwendung handelt es sich um ein Plugin-basiertes Tool mit vielen unterschiedlichen Regelsätzen, das – abhängig vom stattgefundenen Event – dem Benutzer mit Rat und Tat zur Seite steht. Auch lassen sich mehrere Benachrichtigungs-Mechanismen einstellen. So kann der Benutzer veranlassen, dass er eine Mail erhält, wenn das SELinux-System eine nicht erlaubte Aktion unterbindet. Benutzer eines grafischen Desktops haben die Möglichkeit, ein Sealert-Applet in ihre Taskbar einzubinden, um sich direkt durch ein Pop-up über aktuelle Meldungen des Setroubleshoot-Daemon zu informieren. Die Logeinträge der Anwendung finden sich in der Datei »/var/log/messages« (Listing 2).

Listing 2

/var/log/messages

 

Folgt der Benutzer dem Rat des Setroubleshoot-Daemon und ruft den Befehl »sealert« mit den angegebenen Parametern auf, erhält er eine detaillierte Übersicht über das aufgetretene Problem und Informationen darüber, wie er es beheben kann (Listing 3).

Listing 3

sealert

 

Diese Meldung weist schon auf das eigentliche Problem hin. Die Datei »/var/www/html/index.html« besitzt das falsche Security-Label, somit ist ein Zugriff des Webservers hierauf nicht möglich. Eine mögliche Lösung ist ebenfalls aufgeführt:

 

Der Aufruf von »restorecon« sorgt dafür, dass jedes Objekt im Verzeichnis »/var/www/html« das richtige Label bekommt. Danach sollte der Zugriff wieder funktionieren. Aber welches ist in diesem Zusammenhang eigentlich das richtige Label? Es ist jenes, das diese Datei in der binären Policy besitzt. Mit Hilfe von »semanage« bekommt der Admin schon im Vorfeld raus, wie das hinterlegte Label lautet:

 

Was soll der Admin aber machen, um den Zugriff auf ein Objekt zu erlauben, das noch über keinen Eintrag in der Policy verfügt? In einem solchen Fall ist die Datei mit dem gewünschten Label in die Policy aufzunehmen. Das funktioniert ebenfalls mit dem Tool »semanage« . Angenommen das Webserver-Documentroot befindet sich unterhalb von »/www« , dann ist auch dieses Verzeichnis, mit allen darin enthaltenen Dateien, mit dem Label »httpd_sys_content_t« zu versehen. Der folgende Aufruf fügt der Policy einen entsprechenden Eintrag hinzu:

 

Der abschließende Aufruf von »restorecon« setzt das neue Label auf das Verzeichnis und alle darin enthaltenen Dateien.

Genauso wie der Zugriff auf Dateien oder Verzeichnisse anhand eines Security-Labels stattfindet, geschieht es auch mit Netzwerkports. Das Tool »semanage« bindet das Security-Label an einen Port:

 

Hier wird der TCP-Port 8000 mit dem Label »httpd_port_t« versehen. Verifizieren lässt sich dies mit dem erneuten Aufruf von »semanage« :

 

Manchmal funktioniert eine Anwendung im Enforcing-Modus nicht, die Logdatei zeigt jedoch keine Fehlermeldung an. In der Policy existieren nämlich so genannte Dontaudit-Regeln, die einen Zugriff zwar unterbinden, ihn aber nicht loggen. Das ist ganz praktisch, wenn zum Beispiel eine Anwendung Aktionen durchführen will, die für eine korrekte Funktion aber nicht notwendig sind. Da SELinux nach dem "Principle of least Privilege" arbeitet, sind solche Zugriffe nicht erlaubt. Natürlich soll aber auch nicht jedes Mal ein Eintrag im Log erfolgen.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite