Prüfen Sie die Labels, bevor Sie SELinux die Schuld geben

Wenn eine Anwendung auf einem Host mit SELinux im Enforcing-Modus bricht, ist der Reflex in vielen Teams, SELinux auf Permissive zu stellen und weiterzumachen. Wir halten es auf jedem Host, den wir betreiben, auf Enforcing, und nach unserer Erfahrung ist die Ursache meist viel kleiner, als der Reflex vermuten lässt: eine Datei, die das falsche Label trägt. Dieser Artikel zeigt, wie Sie das schnell finden, richtig beheben und dabei vermeiden, sich selbst auszusperren.

Was ein Label ist, und wie es schiefgeht

SELinux trifft Entscheidungen anhand von Labels. Jede Datei und jeder Prozess trägt einen Sicherheitskontext, und die Policy legt fest, welche Prozesstypen was mit welchen Dateitypen tun dürfen. Die Policy legt auch fest, welches Label jeder Pfad haben sollte: Inhalte unter /var/www sollten httpd_sys_content_t sein, ein ausführbares Programm unter /usr/bin sollte bin_t sein, und so weiter. Diese erwarteten Labels sind die File-Context-Regeln.

Eine Datei bekommt ihr Label bei der Erstellung, normalerweise geerbt vom übergeordneten Verzeichnis oder gesetzt durch eine Regel der Policy. Das funktioniert gut, bis Dateien auf ungewöhnlichem Weg ankommen:

• mv behält das ursprüngliche Label, sodass eine Datei, die in einem Home-Verzeichnis erstellt und in ein Web-Root verschoben wurde, weiterhin sagt, sie gehöre in ein Home-Verzeichnis.
• Archive, die ohne SELinux-Attribute entpackt oder aus einem Backup wiederhergestellt wurden, das sie nicht bewahrt hat, bekommen, was das Zielverzeichnis vergibt.
• Inhalte an einem eigenen Ort, etwa /srv/app, bekommen ein generisches Label, weil die Policy für diesen Pfad noch keine Regel hat.

In jedem dieser Fälle ist die Policy in Ordnung. Die Datei trägt schlicht das falsche Label, und der Prozess, der sie braucht, wird abgewiesen.

Lesen Sie zuerst die Verweigerung

Bevor Sie irgendetwas ändern, lesen Sie, was SELinux tatsächlich verweigert hat:

ausearch -m AVC -ts recent

Jede Verweigerung nennt den Prozesstyp (scontext), den Zieltyp (tcontext), die Objektklasse und die Berechtigung. Sieht der Zieltyp für diese Datei falsch aus (ein Webserver, dem das Lesen von etwas mit dem Label user_home_t verweigert wurde, zum Beispiel), sehen Sie mit ziemlicher Sicherheit ein Label-Problem, keine Lücke in der Policy.

Vergleichen Sie, was da ist, mit dem, was da sein sollte

Drei Befehle beantworten die Frage direkt:

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

restorecon -n ändert nichts. Es meldet nur den Unterschied zwischen dem aktuellen und dem erwarteten Label, was es zum perfekten Prüfwerkzeug macht. Lassen Sie es nach einer Installation, einem Restore oder einer Migration über einen ganzen Baum laufen:

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Ein leeres Ergebnis bedeutet, dass jede Datei unter diesen Pfaden das Label trägt, das die Policy erwartet. Jede Zeile in der Ausgabe ist eine Datei, bei der das nicht so ist, und diese Liste ist meist kurz und sehr aufschlussreich. Wir führen diese Art Prüfung auf neuen Builds routinemäßig aus, und unsere Installationsvorlagen relabeln kritische Pfade im Post-Install-Schritt, sodass ein neuer Host sein Leben mit korrekten Labels beginnt, bevor sich jemand anmeldet.

Beheben Sie es auf die richtige Weise

Für eine Datei, die schlicht das falsche Label hat, relabeln Sie sie auf das, was die Policy erwartet:

restorecon -Rv /path

Für einen eigenen Ort, den die Policy nicht kennt, bringen Sie der Policy zuerst die Regel bei und relabeln dann, damit die Korrektur das nächste vollständige Relabel überlebt:

semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?"
restorecon -Rv /srv/app

chcon ändert ebenfalls Labels, aber nur bis zum nächsten Relabel, danach kehrt das Problem zurück. Verwenden Sie es für Experimente, nicht für Korrekturen.

Sind die Labels richtig und die Verweigerung betrifft Verhalten, prüfen Sie die Booleans, bevor Sie Policy schreiben. Viele häufige Bedürfnisse, etwa ein Webserver, der ausgehende Netzwerkverbindungen öffnet, sind ein einziger Schalter:

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Seien Sie misstrauisch gegenüber audit2allow

audit2allow liest Verweigerungen und schreibt ein Policy-Modul, das sie erlaubt. Es erzeugt immer etwas, das funktioniert, und genau das ist die Gefahr. Ist die eigentliche Ursache eine falsch gelabelte Datei, gewährt das erzeugte Modul eine breite Berechtigung, um das Symptom verschwinden zu lassen, und jede andere Datei und jeder Prozess dieses Typs erbt die schwächere Policy. Lesen Sie, was es vorschlägt. Eine Regel, die einer Domain den Übergang in eine sehr privilegierte erlaubt, oder alles eines gängigen Typs zu lesen, ist ein starker Hinweis darauf, dass das Label falsch und das Modul die falsche Korrektur ist. Eigene Module sind manchmal richtig, für hausinterne Software ohne eigene Policy, aber sie sollten der letzte Schritt sein, nicht der erste.

Sicher auf Enforcing gehen auf einem entfernten Host

Eine entfernte Maschine von Permissive auf Enforcing umzustellen ist eine jener Änderungen, die Ihre eigene Sitzung kappen können, wenn noch etwas falsch gelabelt ist. Spannen Sie zuerst ein Sicherheitsnetz, damit der Host sich selbst zurückstellt, wenn Sie den Zugriff verlieren:

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

systemd löst den Timer aus, ob Ihre Sitzung überlebt oder nicht. Brechen Sie ihn erst ab, nachdem eine ganz neue Anmeldung gelungen ist. Dasselbe Muster funktioniert für Firewall-, SSH- und Routing-Änderungen auf einer Maschine, zu der Sie nicht hingehen können.

Eine kurze Checkliste

• Führen Sie restorecon -Rnv nach jeder Installation, jedem Restore und jeder Migration über die Systempfade aus.
• Lesen Sie die AVC-Verweigerung und vergleichen Sie ls -Z mit matchpathcon, bevor Sie die Policy ändern.
• Verwenden Sie semanage fcontext plus restorecon für eigene Pfade, nicht chcon.
• Prüfen Sie die Booleans, bevor Sie ein Modul schreiben.
• Behandeln Sie die Ausgabe von audit2allow als Frage, nicht als Antwort.
• Stellen Sie einen entfernten Host nie ohne zeitgesteuerten Rückweg auf Enforcing.

Wenn ein Anwendungshersteller Ihnen gesagt hat, Sie sollten SELinux abschalten, und Sie das lieber nicht tun würden, helfen wir gern, die genaue Korrektur zu finden. Mit einem Ingenieur sprechen

Related

Verwandt: Die Hardening-Baseline auf jedem Host · Schnelle Reaktion auf Schwachstellen, am selben Tag