In einem früheren Artikel habe ich den Ablauf einer Anwendung beschrieben, die PAM-Bibliotheken zur Authentifizierung auf sehr hohem Niveau aufruft. In diesem Artikel gehen wir durch die Konfigurationsdateien für ein lokales sudo Befehl.
Bei Verwendung von sudo , wir wechseln den Benutzer und tun etwas. Diese Berechtigungsänderung erfordert die Überprüfung, dass wir der sind, von dem wir sagen, dass wir es sind, und dass wir die gegebene Aktion ausführen dürfen. Die /etc/sudoers Datei steuert, wer was tun kann, aber der Prozess ruft PAM weiterhin für alle Authentifizierungsprüfungen auf. Als Teil dieser Aufrufe identifiziert sich der Prozess selbst und dann libpam sucht nach einer passenden Konfigurationsdatei in /etc/pam.d Verzeichnis.
$ cat /etc/pam.d/sudo
#%PAM-1.0
#Type ReturnCode Modules Options
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Wie viele andere *.d-Verzeichnisse kann die Paketverwaltung eine Datei aus diesem Verzeichnis hinzufügen oder daraus entfernen. Das sudo RPM fügt den /etc/pam.d/sudo hinzu Datei.
$ rpm -qf /etc/pam.d/sudo
sudo-1.9.0-0.1.b4.fc31.x86_64
Eine Upstream-Version kann eine Vielzahl von Einträgen haben, aber dieses von der Distribution bereitgestellte Paket enthält eine Konfigurationsdatei mit mehreren include Anweisungen zum gemeinsamen /etc/pam.d/system-auth Datei, die von pam bereitgestellt wird Paket.
Felder der Konfigurationsdatei
Das erste Feld in dieser Datei identifiziert einen Typ des Anrufs bei PAM. Zeilen des gleichen Typs werden zusammengefasst. Es gibt vier Typen:auth, account, password und session. Sehen Sie sich man pam an für eine Beschreibung jedes Typs.
Das zweite Feld ist als ReturnCode bekannt . Dieses Feld teilt PAM mit, wie mit den Ergebnissen des Modultests umzugehen ist. Rückgabecodes geben an, ob ein Test erforderlich oder optional ist. Die Codes können auch verwendet werden, um anzuzeigen, dass es sich bei der Zeile nicht um einen Modultest mit Optionen handelt, sondern um den Namen einer anderen Konfigurationsdatei mit zusätzlichen Prüfungen. Eine vollständige Beschreibung der Rückgabecodes finden Sie in man pam.conf , und die gängigsten werden später in diesem Artikel besprochen.
Der Rest der Zeile enthält den Modulnamen und Optionen für dieses Modul. Der Modulname muss mit einem Modul übereinstimmen, das in /etc/lib64/security verfügbar ist Verzeichnis. Die Optionen können je nach Art des getätigten Anrufs unterschiedlich sein. Einige Module führen nur Tests für einige Anruftypen durch. Verwenden Sie die Manpage für jedes Modul, um Beispiele zu sehen und mehr über die Verwendungsmöglichkeiten und verfügbaren Optionen zu erfahren.
Die Reihenfolge der Einträge innerhalb eines Anruftyps ist von Bedeutung. Dies liegt hauptsächlich daran, wie die Rückkehrcodes verarbeitet werden, aber in einigen Fällen an einer Modulaktion. Wenn libpam eine "done"- oder "die"-Nachricht erhält, meldet er das Gesamtergebnis an den aufrufenden Prozess zurück.
Die Konfiguration für sudo hat mehrere include Linien. Diese Zeilen teilen libpam mit um alle Zeilen des angegebenen Typs aus der angegebenen Konfigurationsdatei einzuschließen. Es gibt auch einen Substack -Option, die ähnlich darin ist, wie sie Zeilen aus einer gegebenen Konfigurationsdatei einschließt, aber bei "done" oder "die" an den Substack zurückmeldet Anweisung anstelle des ursprünglichen Prozesses, der libpam aufruft . Ältere Versionen von PAM hatten andere Variationen darüber, wie andere Konfigurationsdateien enthalten waren. Als ich beispielsweise vor fast 20 Jahren anfing, PAM zu erforschen, gab es ein bestimmtes Modul, das mit den Konfigurationsdateien als Argument aufgerufen wurde. Das Schlüsselwort "include" war für den ReturnCode ungültig Feld.
Rückgabecodes in den zentralen Konfigurationsdateien
Der /etc/pam.d/sudo Die zuvor gezeigte Datei ist ziemlich kurz. Drei der vier Aufruftypen haben nur ein include einer anderen Datei. Der /etc/pam.d/system-auth file ist eher typisch für eine Konfigurationsdatei, mit vielen Prüfungen für jeden Aufruftyp.
$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
...omitted... Das erforderliche Schlüsselwort ist vielleicht das häufigste. Es zeigt an, dass das Modul die Prüfung bestehen muss, damit ein Gesamtbestanden an die Bewerbung zurückgegeben werden kann. Aber auch bei einem Fehler werden die folgenden Zeilen dieses Typs noch geprüft. Dies ist eine langjährige Praxis, keinen Grund für einen Authentifizierungsfehler mitzuteilen. Auf Systemen vor 20 Jahren wäre es möglich gewesen, anhand der Zeit, die bis zum Scheitern gedauert hat, zu erraten, wie die Authentifizierung fehlgeschlagen ist.
Das Erfordernis Schlüsselwort ist ähnlich wie erforderlich , dass die Prüfung bestanden werden muss, aber im Falle eines Fehlschlagens eine "sterben"-Nachricht zurückgibt. Erforderlich lässt libpam wissen, dass die folgenden Zeilen nicht überprüft werden, und um den aufrufenden Prozess über das Gesamtergebnis zu informieren – in diesem Fall ein Fehler.
Die ausreichend Schlüsselwort ist fast das Gegenteil von requisite . Bei Erfolg wird eine „Done“-Meldung zurückgegeben und libpam geht weiter und sendet seine Gesamtergebnisse zurück an die aufrufende Anwendung. Andere Ergebnisse dieses Moduls werden ignoriert und die Prüfung wird fortgesetzt.
Die ausreichend Schlüsselwort ist üblich, wenn es mehrere Möglichkeiten gibt, ein Kriterium zu überprüfen. Wenn Sie beispielsweise ein Passwort verifizieren, könnte der Benutzer im lokalen /etc/passwd definiert sein und /etc/shadow Dateien, oder sie sind möglicherweise nur in einem zentralen System definiert, auf das mit sssd zugegriffen wird . Die pam_unix Modul überprüft die lokalen Dateien. Bei Erfolg ist es nicht erforderlich, die zentralisierten Dienste fortzusetzen und zu überprüfen. Wenn der Benutzer jedoch nicht lokal definiert ist, möchten wir keinen Fehler aufzeichnen, wir möchten das Ergebnis ignorieren und den pam_sss versuchen Modul. Da die ausreichend Schlüsselwort nie wirklich fehlschlägt, ist es üblich, ein erforderliches pam_deny hinzuzufügen Zeile nach einer Reihe von ausreichend Linien. Die pam_deny -Modul schlägt immer ähnlich wie /bin/false fehl ausführbar.
Die optionale Schlüsselwort ist ähnlich wie ausreichend dadurch, dass es alle Fehler ignoriert. Bei Erfolg verhält es sich jedoch eher wie das erforderliche Keyword, indem Sie einen "OK"-Wert festlegen und weitere Überprüfungen durchführen.
Da beides erforderlich ist und ausreichend Austrittspunkte aus dem Modulstapel sein können, ist die Reihenfolge in der Konfigurationsdatei wichtig. Zeilen nach diesen Schlüsselwörtern können ausgeführt werden oder nicht.
Komplexe Rückgabecodes
Über die einfache Schlüsselwortsyntax hinaus werden komplexe Rückgabecodes mit Schlüssel-Wert-Paaren in eckigen Klammern definiert. Der /etc/pam.d/system-auth Datei hat ein Beispiel im Session-Abschnitt der komplexeren Syntax.
$ cat /etc/pam.d/system-auth
...omitted...
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Die komplexe Syntax, die jedem Schlüsselwort entspricht, finden Sie in der pam.conf Manpage. Der - oben gezeigt ist auch in der Manpage definiert. Es zeigt an, dass die Protokollierung übersprungen werden kann, wenn das Modul nicht auf dem System installiert ist.
Was kommt als nächstes?
Jetzt können wir durchgehen, wann ein Aufruf und ein Exit mit libpam erfolgt , besteht der nächste Schritt darin, den Anwendungsfall für jedes Modul besser zu verstehen. Die meisten Module haben eine Handbuchseite, die die Verwendung erklärt und Beispiele für Zeilen zeigt, die in pam.d erscheinen sollten Konfigurationsdateien. Einige der Module verweisen auch auf zusätzliche Dateien in /etc/security Verzeichnis. Diese Dateien sind gut kommentiert und haben oft auch ihre eigene Manpage. Die pam_pwquality und pam_limits Module sind gute Beispiele für den Einstieg.
Abschluss
Im nächsten Artikel werde ich einige der Änderungen durchgehen, die mit authconfig vorgenommen wurden Nützlichkeit. Wenn Sie Dateien selbst bearbeiten möchten und über eine Red Hat Learning Subscription verfügen, lesen Sie das Kapitel zu PAM im Kurs Red Hat Security:Linux in Physical, Virtual, and Cloud (RH415).
[ Kostenloser Online-Kurs:Technischer Überblick zu Red Hat Enterprise Linux. ]