Nachdem der Theorie zur PAM-Konfiguration hier nun ein praktisches Beispiel, die sshd PAM-Konfiguration:
Beispiel 21.1. PAM-Konfiguration für sshd
#%PAM-1.0 auth include common-auth auth required pam_nologin.so account include common-account password include common-password session include common-session # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE) #session optional pam_resmgr.so fake_ttyname
Die typische PAM-Konfiguration für eine Anwendung (in diesem
Fall sshd) umfasst vier include-Statements, die sich auf die
Konfigurationsdateien für vier Modultypen beziehen:
common-auth,
common-account, common-password
und common-session. Diese vier Dateien
enthalten die Standardkonfigurationen für jeden Modultyp.
Indem Sie die Dateien via include einbeziehen, anstatt
die Module für jede PAM-Anwendung gesondert aufzurufen,
erhalten Sie eine aktualisierte PAM-Konfiguration, sobald der
Administrator die Standardwerte ändert. Früher mussten
bei Änderungen in PAM oder bei der Installation einer
neuen Anwendung die Konfigurationsdateien für alle
Anwendungen manuell angepasst werden. Die PAM-Konfiguration
und alle Änderungen werden nun von den
Standardkonfigurationsdateien geerbt.
Die erste include-Datei (common-auth)
ruft zwei Module des Typs auth auf:
pam_env und
pam_unix2. Siehe Beispiel 21.2, „Standardkonfiguration der auth-Section“.
Beispiel 21.2. Standardkonfiguration der auth-Section
auth required pam_env.so auth required pam_unix2.so
Das erste Modul pam_env liest die Datei
/etc/security/pam_env.conf ein und setzt die dort
spezifizierten Umgebungsvariablen. Hier lässt sich beispielsweise die
DISPLAY-Variable auf den richtigen Wert setzen, da
pam_env Informationen darüber erhält, von wo sich ein
Benutzer einzuloggen versucht.
Das zweite Modul pam_unix2
vergleicht Login und Passwort des Benutzers mit
/etc/passwd und
/etc/shadow.
Nachdem die in common-auth angegebenen
Module erfolgreich aufgerufen wurde überprüft ein
drittes Modul namens pam_nologin,
ob die Datei /etc/nologin existiert.
Ist dies der Fall, so darf sich kein Benutzer außer
root einloggen.
Der Stapel (engl. stack), der auth-Module
wird abgearbeitet, bevor der ssh-Daemon eine
Rückmeldung darüber bekommt, ob die Anmeldung erfolgreich war.
Alle Module tragen hier den Kontroll-Flag required und
müssen sämtlich erfolgreich abgearbeitet worden sein, bevor die
Erfolgsmeldung an sshd abgesetzt wird. Schlägt
eines dieser Module fehl, bewirkt das zwar, dass das Endergebnis negativ
ist, aber sshd erfährt davon erst, wenn alle
Module dieses Typs abgearbeitet wurden.
Sobald alle Module des Typs auth erfolgreich
abgearbeitet wurden, wird ein weiteres include-Statement
abgearbeitet, in diesem Fall das in Beispiel 21.3, „Standardkonfiguration der account-Section“
gezeigte. common-account enthält lediglich
ein Modul, pam_unix2. Wenn pam_unix2
das Ergebnis liefert, dass der Benutzer existiert, so erhält
sshd eine Mitteilung über diesen Erfolg, und der nächste
Modulstapel (password) wird abgearbeitet,
wie in Beispiel 21.4, „Standardkonfiguration der password-Section“ gezeigt.
Beispiel 21.4. Standardkonfiguration der password-Section
password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok #password required pam_make.so /var/yp
Die PAM-Konfiguration für sshd beinhaltet wiederum
nur ein include-Statement, dass auf die Standardkonfiguration
für password-Module in
common-passwordweist.
Diese Module müssen erfolgreich abgearbeitet werden (Kontroll-Flag:
required), wenn die Anwendung das
Authentifizierungstoken ändert. Um ein Passwort oder ein anderes
Authentifizierungstoken zu ändern, muss es auf seine Sicherheit geprüft
werden. Dies erfolgt mit Hilfe des PAM-Moduls
pam_pwcheck. Das danach benutzte
pam_unix2-Modul übernimmt die alten und neuen
Passwörter von pam_pwcheck. So muss der Benutzer sich
nicht erneut authentifizieren. Außerdem wird so ein Umgehen der Checks von
pam_pwcheck verhindert. Die Module vom Typ
password sollten immer dann aufgerufen werden, wenn die
vorangestellten Module für account oder
auth ein abgelaufenes Passwort bemängeln.
Beispiel 21.5. Standardkonfiguration der session-Section
session required pam_limits.so session required pam_unix2.so
Zum Abschluss werden die Module vom Typ session,
die in der Datei common-session gebündelt sind,
aufgerufen, um die Session den Vorgaben für diesen Benutzer entsprechend zu
konfigurieren. Das pam_unix2-Modul wird hier zwar
erneut aufgerufen, mit der in pam_unix2.conf
(die Konfigurationsdatei dieses Moduls) angegebenen
Option none hat dieser Aufruf
aber keinerlei praktische Auswirkungen. Das Modul
pam_limits liest die Datei
/etc/security/limits.conf ein, in der eventuelle
Limits für die Benutzung von Systemressourcen festgelegt werden können.
Loggt der Benutzer sich wieder aus, werden die
session-Module erneut aufgerufen.