Root im Terminal, unter SELinux verweigert: warum der Hook scheitert

Sie führen das up-Skript als root aus, es läuft durch, und dasselbe Skript scheitert, wenn der Dienst es aufruft. An den Dateiberechtigungen hat sich nichts geändert, also ist der naheliegende nächste Schritt, sie erneut zu lockern, was nichts behebt. Auf einem SELinux-Host ist der entscheidende Faktor oft nicht, wer der Prozess ist, sondern in welcher Domäne er läuft, und root innerhalb einer eingeschränkten Domäne bleibt eingeschränkt.

Derselbe Befehl, zwei verschiedene Sicherheitsdomänen

Die Typerzwingung bewertet die Quellendomäne, das Ziellabel und die angeforderte Operation gemeinsam. Ihre Terminalsitzung läuft in einer unbeschränkten oder administrativen Domäne, und der Daemon läuft in der Domäne, die seiner Unit zugewiesen ist. Identische Befehle führen daher zu unterschiedlichen Entscheidungen, und der Unterschied ist beabsichtigt und kein Fehler in der Richtlinie.

Deshalb ist der Vergleich der beiden Läufe nur nützlich, wenn Sie ihre Kontexte vergleichen. Führen Sie denselben Befehl aus der Shell und aus dem Hook aus: Die Shell-Version beweist, dass die Binärdatei existiert und die Argumente stimmen; sie beweist nichts darüber, ob der Dienst sie ausführen darf. Führen Sie ihn auf beiden Wegen aus und vergleichen Sie die Domänen, nicht nur die Exit-Codes. Genau dieser Vergleich verwandelt eine vage Berechtigungsbeschwerde in eine konkrete Frage zu einer Domäne und einem Label.

Die klassische Form dieses Fehlers ist ein Helfer, der ein externes Werkzeug aufruft. Der Hook selbst mag erlaubt sein, während das aufgerufene Werkzeug ein Label trägt, das die Dienstdomäne nicht ausführen darf, oder in ein Verzeichnis schreibt, dessen Label es verbietet.

Lesen Sie den AVC-Eintrag neben dem Hook-Fehler

Eine AVC-Verweigerung nennt die Felder, die den Fall entscheiden: den Quellkontext des Prozesses, den Zielkontext des Objekts, die Objektklasse und die konkret verweigerte Berechtigung. Lesen Sie alle vier, bevor Sie eine Theorie bilden, denn eine Verweigerung bei execute und eine bei write haben völlig unterschiedliche Reparaturen.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Der Quellkontext sollte zur Domäne passen, in der der Dienst tatsächlich läuft, und der Zielkontext zum Label der Datei oder des Verzeichnisses, das die Operation berührt hat. Wenn eines davon nicht zu dem Fehler passt, dem Sie nachgehen, lesen Sie ein anderes Ereignis.

Notieren Sie die Richtlinienversion und den genauen Pfad der ausführbaren Datei neben dem Eintrag. Ein Domänenname, der in der Richtlinie einer Distribution vorkommt, ist ein Beleg für diese Installation, keine Garantie, dass ein anderer Build dieselben Regeln mitbringt. Dieser Kontext ist es, der es anderen ermöglicht, Ihre Schlussfolgerung auf ihrem eigenen Host nachzuvollziehen. Ohne ihn liest sich der Eintrag wie eine Anekdote und nicht wie ein Beleg.

Label, Konfiguration oder Richtlinie: drei Reparaturen

Die erste Reparatur ist ein Label, das nicht zum installierten Speicherort der Datei passt. Ein mit cp an seinen Platz kopiertes oder von einem Editor geschriebenes Skript kann ein Standardlabel tragen, das die Dienstdomäne nicht verwenden kann, und die Wiederherstellung des erwarteten Kontexts behebt das, ohne die Richtlinie überhaupt anzufassen.

Die zweite ist die Konfiguration. Die Distribution bietet vielleicht einen unterstützten Weg, die Operation auszuführen, ein dokumentiertes Verzeichnis für den Helfer oder ein aktualisiertes Richtlinienpaket, das sie bereits erlaubt. Ihr Layout auf das unterstützte zu ändern ist billiger als Richtlinien zu schreiben und übersteht Aktualisierungen.

Die dritte ist eine wirklich fehlende Regel, und sie sollte das letzte Mittel sein. Erzeugen Sie einen Kandidaten mit den Audit-Werkzeugen, lesen Sie, was er tatsächlich erlaubt, verengen Sie ihn auf die beobachtete Operation und Domäne, und lassen Sie ihn von jemand anderem prüfen, bevor er der Produktion nahekommt.

Warum ein altes Allow-Modul nicht die Antwort ist

Suchergebnisse zu diesem Fehler sind voll von vorgefertigten Modulen, oft für ein Werkzeug, das der Hook nicht mehr aufruft. Ein installiertes Modul gewährt Berechtigungen, die mit Ihrer Verweigerung nichts zu tun haben müssen, und es lässt die eigentliche Unstimmigkeit bestehen, während es ein dauerhaftes Loch hinzufügt.

Es verdeckt auch den nächsten Fehler. Ein Modul, das eine breite Klasse von Operationen erlaubt, lässt diesen Fehler verschwinden und macht den folgenden zu etwas viel schwerer Zuzuordnendem. Das Modul später zu entfernen ist ebenfalls eine Änderung, die niemand einplanen will, also wird die Abkürzung tendenziell dauerhaft.

Der disziplinierte Vergleich ist der zwischen der Verweigerung, die Sie lesen können, und der Änderung, die Sie vorschlagen. Red Hats Leitfaden zur Fehlerbehebung bei SELinux stellt Label- und Konfigurationsprüfungen genau aus diesem Grund vor generierte Richtlinien. Wenn im Eintrag keine entsprechende Verweigerung steht, ist SELinux wahrscheinlich nicht Ihr Problem, und Probleme mit Pfad, Sandbox oder Berechtigungen sind weiterhin offen.