PAM-Authentifizierung funktioniert von Hand, scheitert aber als OpenVPN-Dienst

Die Authentifizierung über PAM kann gelingen, wenn Sie den Client von Hand starten, und mit AUTH_FAILED scheitern, sobald systemd dasselbe Profil startet. Das Passwort ändert sich zwischen diesen Läufen nicht; geändert wird der Satz von Einschränkungen um den Prozess, der PAM die Frage stellt. PAM antwortet über einen Helfer, dessen Fähigkeit, seine eigenen Anmeldedaten zu ändern, genau das ist, was eine gehärtete Unit entfernt. Finden Sie diesen Helfer und die Grenze, die er braucht, bevor Sie eine Capability-Liste anfassen.

unix_chkpwd ist das Binärprogramm, das die PAM-Frage beantwortet

Bei lokaler Passwortauthentifizierung liest pam_unix selten selbst die Hash-Datei. Es führt unix_chkpwd aus, das Distributionen als setuid root oder setgid shadow installieren, damit ein Passwort im Auftrag eines Prozesses geprüft werden kann, der /etc/shadow nichts zu lesen hat. Entfernen Sie die Möglichkeit, diese Identität zu erlangen, und der Helfer kann die Prüfung nicht abschließen, weshalb das Modul einen schlichten Authentifizierungsfehler zurückgibt.

Der Fehler sieht dann in jedem Protokoll, das der Client sieht, wie ein Problem mit den Anmeldedaten aus. Das ist die Falle: Der Client meldet, was PAM ihm gesagt hat, und PAM meldet nur, dass der Stack Nein gesagt hat. Den Helfer von Hand als root auszuführen beweist ebenfalls nichts, weil er einen Privilegienpfad ausübt, den der Dienst nie nutzt. Lesen Sie die Unit, die systemd tatsächlich geladen hat, und dann das Systemprotokoll für den unternommenen Versuch. Diese beiden Sichten trennen ein Sandbox-Problem von einem Falschpasswort-Problem.

Lesen Sie die Unit, bevor Sie das Passwortprotokoll lesen

Eine paketierte Unit kann ein Drop-in tragen, das Sie nicht geschrieben haben, und die effektive Konfiguration ist das zusammengeführte Ergebnis. Geben Sie die Unit so aus, wie systemd sie sieht, zusammen mit den Sandbox-Einstellungen, die entscheiden, ob der Helfer sich selbst erhöhen kann. Eine reine Leseinspektion reicht in dieser Phase.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Der erste Befehl zeigt, woher die Unit und ihre Drop-ins kommen, was wichtig ist, weil eine vor Monaten hinzugefügte Überschreibung länger lebt als die Erinnerung daran, warum es sie gibt. Der zweite gibt die Sandbox-Werte aus, von denen die nächsten beiden Abschnitte abhängen.

Vergleichen Sie, was Sie sehen, mit einem funktionierenden Host derselben Distribution und Version. Ein Unterschied bei User, CapabilityBoundingSet oder NoNewPrivileges ist eine konkrete Spur; ein Unterschied in Prosa-Kommentaren nicht. Notieren Sie die Werte, bevor Sie etwas ändern, denn ein späterer Vergleich mit einem beweglichen Ziel beweist nichts. Läuft der Dienst unter einem unprivilegierten Konto mit leerem Bounding-Set, hat der Helfer fast nichts, womit er arbeiten kann.

Anmeldedatenumwandlung, Dateizugriff und Richtlinie sind drei Grenzen

Beginnen Sie mit dem, was während exec geschieht. Ein setuid-Binärprogramm oder eine Datei mit Datei-Capabilities löst eine Anmeldedatenumwandlung aus, sodass die resultierende Identität keine Fortsetzung des Aufrufers ist. Das Bounding-Set begrenzt, was ein solches Programm erwerben darf, und NoNewPrivileges blockiert setuid-, setgid- und Datei-Capability-Gewinne vollständig. Jede der drei kann den Helfer stoppen, während jede andere Dienstfunktion intakt bleibt.

Trennen Sie als Nächstes die breite diskretionäre Umgehung vom engen Lesezugriff. CAP_DAC_OVERRIDE überspringt diskretionäre Prüfungen fast überall, während CAP_DAC_READ_SEARCH Lesen und Verzeichnisdurchquerung mit eigenen Zusatzbefugnissen abdeckt. Es sind verschiedene Werkzeuge mit unterschiedlichen Wirkungsradien, und keines ist eine Schreibweise für lass PAM die Shadow-Datei lesen.

Fragen Sie schließlich, ob die obligatorische Richtlinie die Aktion überhaupt erlaubt. Eine Linux-Capability hebelt SELinux nicht aus, und eine zu besitzen beweist nichts über eine Type-Enforcement-Regel. Behandeln Sie eine Dateizugriffsverweigerung und eine Capability-Verweigerung als unterschiedliche Belege, denn sie benennen unterschiedliche Korrekturen und oft unterschiedliche Zuständige. Lesen Sie jedes Feld des Datensatzes statt nur das Wort denied. Welche ausführbare Datei gehandelt hat, in welcher Domäne sie lief, welchen Zieltyp sie berührte, welche Objektklasse beteiligt war und welche Berechtigung die Richtlinie verweigerte – jedes verengt die Antwort auf andere Weise.

Ziehen Sie die Verweigerung aus dem Audit-Protokoll

Auf einem durchsetzenden Host ist der Audit-Trail der einzige Ort, der eine Verweigerung aufzeichnet. Fragen Sie die jüngsten Ereignisse ab und lesen Sie sie gegen den Zeitstempel der fehlgeschlagenen Anmeldung, nicht gegen die Zeit, zu der Sie mit der Untersuchung begannen.

ausearch -m AVC,USER_AVC -ts recent

Ein leeres Ergebnis ist kein Beweis für Unschuld. Es bedeutet entweder, dass die Auditierung nicht sammelt, oder dass Ihr Zeitfenster den Versuch verpasst hat, und beide Möglichkeiten müssen ausgeschlossen werden, bevor Sie die Richtlinie ausschließen.

Die SELinux-Fehlerbehebungsanleitung von Red Hat stellt Label- und Konfigurationsprüfungen vor die Erzeugung von Allow-Regeln, was auch für dieses Problem die richtige Reihenfolge ist. Ein falsch gelabeltes Helfer-Binärprogramm und eine Lücke in der Richtlinie erzeugen ähnliche Verweigerungen, erfordern aber unterschiedliche Reparaturen. Eine Allow-Regel für einen Label-Fehler zu erzeugen verdeckt den Defekt und überlässt es dem nächsten Paketupdate, ihn wieder einzuführen. Bestätigen Sie das Label des installierten Helfers, bevor Sie eine Richtlinie schreiben.

Beweisen Sie die Änderung mit einer akzeptierten und einer abgelehnten Anmeldung

Ändern Sie nur die Grenze, die Sie nachgewiesen haben, und testen Sie dann beide Ausgänge. Ein Konto, das sich authentifizieren soll, muss erfolgreich sein, und ein Konto mit falschem Passwort muss weiterhin scheitern. Eine Änderung, die jeden Versuch gelingen lässt, hat die Authentifizierung entfernt statt repariert.

Führen Sie einen echten Verbindungsversuch aus und lesen Sie unmittelbar danach das Journal. Die Zeile, die die Korrektur beweist, ist der pam_unix(openvpn:auth)-Eintrag für diesen Versuch: Sie sollte erfolgreiche Authentifizierung zeigen, und kein AVC-Datensatz darf dieselbe Sekunde tragen.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Ein funktionierender Tunnel braucht auch eine Wiederverbindung, weil Sandbox-Änderungen die zweite Verbindung häufiger brechen als die erste. Prüfen Sie den aufgebauten Socket nach der Wiederverbindung und bestätigen Sie, dass dieselbe Unit ihn weiter bedient.