Die Konfiguration für den Zugriff auf jeweiligen Datenbank-Backends hängt von der
jeweils zu nutzenden Datenbank ab. Im Falle von LDAP z.B. erfolgt die
Konfiguration der LDAP Anbindung von PAM und der
Namensauflösung je nach Distribution in
der Datei /etc/ldap.conf
(SuSE) oder in
/etc/libnss-ldap.conf
(Debian nsswitch) bzw.
/etc/pam_ldap.conf
(Debian PAM).
Die Konfiguration der einzelnen PAM Module selbst erfolgt durch eine zentrale
Konfigurationsdatei für alle Dienste oder mit Hilfe einer einzelnen Konfigurationsdatei
für jeden einzelnen Dienst. Als zentrale Konfigurationsdatei ist
in der Regel die Datei /etc/pam.conf
vorkonfiguriert. Einzelne Konfigurationsdateien
werden typischerweise im Verzeichnis /etc/pamd.d
abgelegt.
Die Konfigurationsdateien sind ähnlich aufgebaut. Die Konfiguration in /etc/pam.conf erfolgt zeilenweise, wobei jede Zeile mit der Bezeichnung des Dienstes begonnen wird.
service_name module-type control-flag module-path arguments
Bei der verzeichnisbasierten Konfiguration wird für jeden Service eine Datei angelegt. Hier entfällt der service-name, der durch den Dateinamen dargestellt wird. Der Aufbau der Zeilen ist hier
module-type control-flag module-path arguments
Eine fehlerhafte Konfiguration des PAM Systems bewirkt, daß der Zugriff in jedem Fall fehlschlägt.
module-type
Der module-type ist einer der oben beschriebenen Modultypen und legt das Modul für den jeweiligen Aufgabenbereich fest.
control-flag
Die einzelnen Module kennen liefern einen Booleschen Wert je nach Erfolg oder Mißerfolg zurück. Mit Hilfe des control-flags kann das Verhalten des Moduls eingestellt werden. Linux-PAM kann mittels zweier unterschiedlicher Syntax Schemata konfiguriert werden. Die ältere Syntax basiert auf Keywords, die neuere auf value=action Paaren.
Bei der Keyword Syntax kann das Verhalten des Moduls mit vier unterschiedlichen Keywords eingestellt werden.
required
Legt fest, daß dieses Modul auf jeden Fall eine
erfolgreiche Ausführung zurückgeben muß, damit die
Ausführung dieses Typs als erfolgreich gewertet wird. Ein
Mißerfolg eines required
Moduls wird erst
erkennbar, wenn alle Module dieses Typs aufgerufen worden
sind.
requisite
Ein Modul mit dem Kontroll-Flag requisite
muß erfolgreich ausgeführt werden. Im Falle eines
Fehlschlags wird die Kontrolle sofort an die aufrufende Applikation
zurückgegeben. An die Applikation wird der Wert
zurückgegeben, der vom ersten fehlgeschlagenen Modulaufruf
zurückgegeben wurde.
sufficient
Eine erfolgreiche Ausführung eines als
sufficient
gekennzeichneten Moduls unterbricht die
Ausführung aller Module dieses Modultyps und gibt eine
erfolgreiche Ausführung des Typs zurück, wenn kein
required
Modul einen Fehlschlag zurückgibt.
optional
Dieses Flag kennzeichnet ein Modul, daß nicht kritisch für den Erfolg oder Mißerfolg dieses Modultyps ist. Der Rückgabewert eines so konfigurierten Moduls wird nur beachtet, wenn alle anderen Module dieses Typs einen Wert wie PAM_IGNORE zurückgibt.
module-path
Der module-path
gibt den Modulnamen oder den absoluten
Pfad zum jeweiligen Modul an. Ein relativer Pfad gibt den Pfad relativ
zum Verzeichnis /lib/security
(Debian) oder
/usr/lib/security
an.
arguments
Die Werte, die unter arguments
eingestellt werden,
werden beim Aufruf an das Modul übergeben. Neben den für das
einzelne Modul spezifischen Argumenten sollte jedes Modul die
folgenden optionalen Argumente auswerten.
debug
Schreibt Debuginformationen perl syslog(3) ins Logfile.
no_warn
Das Modul soll keine Warnungen an die Applikation zurückgeben.
use_first_pass
Das (password-) Modul soll den Benutzer nicht nach einem Passwort fragen. Stattdessen erhält die Applikation das vorher eingegebene Passwort (vom vorhergehenden auth Modul) und nutzt dieses. Der Benutzer wird nicht authentifiziert, wenn dieses Verfahren fehlschlägt. Diese Option ist ausschließlich für auth und password Module vorgesehen.
try_first_pass
Das Modul sollte die Authentisierung mit dem vorher eingegebenen Passwort (des vorhergehenden auth Moduls) versuchen. Diese Option ist ausschließlich für auth Module vorgesehen.
use_mapped_pass
Diese Option sollte das Modul anweisen, die einem vorherigen Modul angegebene Klartext-Passphrase zur Erzeugung eines korrekten Schlüssels zur Ver- und Entschlüsselung des Authentizierungstokens dieses Moduls zu benutzen. In diesem Falle kann der Benutzer einmalig ein Passwort für eine Reihe (Stapel) unterschiedlicher konfigurierter (Backend-) Module in denen das Passwort gespeichert wird, nutzen. Diese Option benötigt unter Umständen starke Verschlüsselungsalgorithmen, so daß sie daher aufgrund der U.S. Exportrichtlinien nicht überall (vollständig) implementiert ist. Die Option ist ausschließlich für auth und password Module vorgesehen.
expose_account
Die expose_account Option kann ein Modul so einstellen, daß es beim Dialog mehr Informationen über den Benutzer angibt. Auf diese Weise erscheint dieser Dialog dem Benutzer ein wenig "freundlicher". Das es aus Sicherheitsgründen oft unerwüscht ist, bei der Authentisierung zu viele Informationen preis zu geben, muß dieses Verhalten vom Administrator explizit aktiviert werden.
Jede (PAM-) Applikation sucht die PAM-Konfiguration in
/etc/pam.conf
mit dem passenden service-name oder im
Verzeichnis /etc/pam.d
nach dem entsprechenden File. Wenn
die entsprechende Konfiguration für den einzelnen Service nicht
gefunden wird, wird versucht eine Konfiguration der Sektion
other oder eine Datei other
im Verzeichnis pam.d
zu finden. Aus Sicherheitsgründen sollte die Konfiguration hier
sehr restriktiv sein.
# # /etc/pam.d/other # auth required pam_deny.so auth required pam_warn.so account required pam_deny.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.soMit dieser Konfiguration schlägt jeder Versuch das PAM System zu nutzen fehl
pam_deny.so
und wird zusätzlich
mitgeloggt pam_warn.so
.
Die Defaultkonfiguration kann natürlich auch dazu genutzt werden, alle nicht explizit zu konfigurierenden Dienste gegen die System-Passwortdatenbank zu authentisieren.