PAM-Konfigurationsdateien

PAM-Dienstnamen

Der Dienstname jeder PAM-aktiven Anwendung ist der Name der Konfigurationsdatei in /etc/pam.d dieser Anwendung. Jedes Programm, das PAM verwendet, definiert seinen eigenen Dienstnamen.

Das Programm login definiert den Dienstnamen login, ftpd definiert den Dienstnamen ftp usw.

Generell ist der Dienstname der Name des Programms, das zum Zugriff auf den Dienst verwendet wird und nicht das Programm, das den Dienst bereitstellt.

PAM-Module

PAM enthält vier verschiedene Modultypen für die Zugriffskontrolle auf bestimmte Dienste:

• auth-Module nehmen die eigentliche Authentifizierung vor (z.B. durch Erfragen und Überprüfen des Passworts) und erstellen Berechtigungsmerkmale, wie z.B. Mitgliedschaft in einer Gruppe oder Kerberos-Tickets.

• account-Module prüfen, ob die Authentifizierung erlaubt ist (der Account darf nicht abgelaufen sein, der Benutzer muss für die Anmeldung um diese Uhrzeit zugelassen sein usw.).

• password-Module dienen zum Setzen von Passwörtern.

• session-Module sorgen dafür, dass ein Benutzer nach seiner Authentifizierung seinen Account benutzen kann, z.B. durch das Mounten des Home-Verzeichnisses des Benutzers oder durch Aktivierung der Mailbox.

Diese Module können gestapelt werden, so dass mehrere Module verwendet werden können. Die Reihenfolge der gestapelten Module ist für den Authentifikationsprozess sehr wichtig, weil es dadurch für einen Administrator einfacher wird, zu erkennen, dass bereits einige Voraussetzungen erfüllt sind, bevor die Benutzerauthentifizierung stattgefunden hat.

Zum Beispiel verwendet rlogin in der Regel vier gestapelte Authentifizierungsmethoden, wie in der PAM-Konfigurations- datei zu sehen:

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

Bevor rlogin ausgeführt wird, stellt PAM fest, dass die /etc/nologin Dateien nicht existieren, dass sie auch nicht als Root angemeldet sind und dass alle Umgebungsvariablen geladen werden können. Wenn die rhosts -Authentifizierung erfolgreich ist, kann die Verbindung zugelassen werden. Ist die Authentifizierung nicht erfolgreich ist, wird zur Standardauthentifizierung mit Passwort übergegangen.

Es können jederzeit neue PAM-Module hinzugefügt werden. PAM-kompatible Anwendungen können dann so angepasst werden, dass diese Module verwendet werden können. Falls Sie z.B. über ein Rechensystem für Einmal-Passwörter verfügen und festlegen können, dass es von einem PAM-Modul unterstützt werden soll, sind PAM-kompatible Programme in der Lage, das neue Modul zu verwenden und mit dem neuen Rechensystem für Einmal-Passwörter zu arbeiten, ohne dass es neu kompiliert oder anderweitig modifiziert werden müsste. Das ist sehr nützlich, da Sie dadurch sehr schnell Authentifizierungsmethoden mit verschiedenen Programmen vermischen und vergleichen sowie testen können, ohne die Programme dafür neu kompiliert zu haben.

Dokumentationen über das Schreiben von Modulen finden Sie unter /usr/share/doc/pam—<version- number>.

PAM Steuer-Flags

Alle PAM-Module erstellen bei einer Überprüfung Fehler- oder Erfolgsmeldungen. Die Steuer-Flags geben PAM an, was mit diesen Ergebnissen geschehen soll. Während Module in einer bestimmten Reihenfolge gestapelt werden können, können Sie mit den Steuer-Flags die Wertigkeit eines Moduls in Bezug auf die nachfolgenden Module einstellen.

Die rlogin PAM-Konfigurationsdatei sieht dann wie folgt aus:

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

Nachdem der Modultyp festgelegt wurde, entscheidet das Steuer-Flag wie wichtig ein bestimmte Modul in Bezug auf das Gesamtziel ist, diesem Benutzer den Zugriff zu dem Programm zu erlauben.

Vier Arten von Steuer-Flags sind für PAM standartmäßig festgelegt:

• Mit required gekennzeichnete Module müssen erfolgreich überprüft werden, bevor die Authentifizierung erfolgen kann. Wenn ein required Modul Fehler entdeckt, wird der Benutzer dann darüber informiert, wenn auch alle anderen Module des gleichen Modultyps überprüft worden sind.

• Mit requisite gekennzeichnete Module müssen ebenfalls überprüft werden, bevor die Authentifizierung erfolgreich sein kann. Wenn ein requisite Modul jedoch Fehler entdeckt, wird der Benutzer hierüber sofort informiert. Diese Mitteilung zeigt das erste fehlerhafte required oder requisite-Modul an.

• Bei sufficient gekennzeichneten Modulen werden Fehler ignoriert. Wenn ein sufficient Modul jedoch erfolgreich überprüft wurde, und kein required Modul fehlschlägt, werden keine weiteren Module dieses Modultyps überprüft, und dieser Modultyp gilt als erfolgreich überprüft.

• optional gekennzeichnete Module sind für die erfolgreiche oder fehlgeschlagene Authentifizierung dieses Modultys nicht von Bedeutung. Sie werden dann wichtig, wenn kein anderes Modul dieses Modultyps erfolgreich war oder fehlgeschlagen ist. In diesem Fall bestimmt der Erfolg oder Misserfolg eines optional Moduls die gesamte PAM-Authentifikation für diesen Modultyp. .

Eine neuere Steuer-Flag Syntax mit immer mehr Kontrollmöglichkeiten steht nun für PAM zur Verfügung. Mehr Informationen über diese neue Syntax finden Sie in den PAM-Dokumentationen unter /usr/share/doc/pam—<version-number> .

PAM Modul-Pfade

Modulpfade geben PAM an, wo die Pluggable Module zu finden sind, die von dem ausgewählten Modultyp verwendet werden. Sie geben üblicherweise den kompletten Pfad zu einem Modul an, wie zum Beispiel /lib/security/pam_stack.so. Wenn der komplette Pfad jedoch nicht angegeben ist (oder anders ausgedrückt: der Pfad beginnt nicht mit einem /) wird angenommen, dass sich das angegebene Modul in der Datei /lib/security (die Standardspeicherstelle für PAM-Module) befindet. modules.

PAM-Argumente

PAM verwendet Argumente, um während der Authentifizierung Informationen über einen bestimmten Modultyp an Pluggable Module zu übermitteln. Mit diesen Argumenten können die PAM-Konfigurationsdateien bestimmter Programme gemeinsame PAM-Module in unterschiedlicher Weise verwenden.

Zum Beispiel verwendet das Modul pam_userdb.so versteckte Dateien aus der Berkeley DB-Datei, um den Benutzer zu authentifizieren. (Berkeley DB ist ein in vielen Anwendungen eingebundenes Open-Source-Datenbank System, das zum Aufspüren einer bestimmten Art von Informationen erstellt wurde.) Das Modul verwendet ein db Argument, das für die verschiedenen Serviceleistungen unterschiedlich sein kann, und spezifiziert den von Berkeley DB zu verwendenden Dateinamen.

Eine pam_userdb.so Zeile in einer PAM- Konfigurationsdatei sieht wie folgt aus:

auth      required  /lib/security/pam_userdb.so db=path/to/file

Ungültige Argumente werden ignoriert und wirken sich auch nicht auf den Erfolg oder Misserfolg eines PAM-Moduls aus. Wenn ein ungültiges Argument auftaucht, erscheint in /var/log/messages normalerweise eine Fehlermeldung. Wenn jedoch diese Methode der Fehlermeldung durch ein PAM-Modul überwacht wird, muss das Modul den Fehler korrekt anzeigen.

Beispiele für PAM-Konfigurationsdateien

Eine Konfigurationsdatei einer PAM-Anwendung sieht wie folgt aus:

#%PAM-1.0
auth      required  /lib/security/pam_securetty.so
auth      required  /lib/security/pam_unix.so shadow nullok
auth      required  /lib/security/pam_nologin.so
account   required  /lib/security/pam_unix.so
password  required  /lib/security/pam_cracklib.so
password  required  /lib/security/pam_unix.so shadow nullok use_authtok
session   required  /lib/security/pam_unix.so

Die erste Zeile ist ein Kommentar (Kommentarzeilen beginnen immer mit den Zeichen #). Die Zeilen zwei bis vier stapeln drei Module für die Authentifizierung bei der Anmeldung.

auth      required  /lib/security/pam_securetty.so

Wenn der Benutzer sich als Root anzumelden versucht, stellt Zeile zwei sicher, dass das Terminal, an dem er sich anmeldet, in der Datei /etc/securetty aufgeführt ist, falls solch eine Datei existiert.

auth      required  /lib/security/pam_unix.so shadow nullok

Zeile drei sorgt dafür, dass der Benutzer nach dem Passwort gefragt wird und dass dieses überprüft wird

auth      required  /lib/security/pam_nologin.so

Zeile vier prüft, ob die Datei /etc/nologin existiert. Falls sie existiert, und der Benutzer nicht als Root angemeldet ist, schlägt die Authentifizierung fehl.

Beachten Sie, dass alle drei auth Module überprüft werden, auch wenn schon beim ersten auth Modul Fehler auftreten. Dadurch wird verhindert, dass Benutzer erfahren, weshalb ihre Authentifizierung nicht zugelassen wurde. Der Grund dafür ist: Wenn ein Benutzer weiß, weshalb seine Authentifizierung abgelehnt wurde, ist es für ihn einfacher, diese zu knacken. Sie können diese Einstellung ändern, indem Sie statt required requisite eintragen. Wenn alle requisite Module Fehlermeldungen liefern, bricht PAM sofort ab, ohne weitere Module aufzurufen.

account   required  /lib/security/pam_unix.so

Die fünfte Zeile veranlasst die Prüfung des Benutzeraccounts. Wenn z.B. Shadow-Passwörter aktiviert worden sind, überprüft das Modul pam_unix.so, ob der Account abgelaufen ist oder ob der Benutzer keine Passwortänderung vorgenommen hat und die Nachfrist für eine Änderung abgelaufen ist.

password  required  /lib/security/pam_cracklib.so

Die sechste Zeile unterzieht das gerade geänderte Passwort einer Reihe von Prüfungen, um sicherzustellen, dass es z.B. nicht auf einfache Weise, durch ein wörterbuchbasiertes Programm zum Knacken von Passwörtern, herausgefunden werden kann.

password  required  /lib/security/pam_unix.so shadow nullok use_authtok

Die siebte Zeile gibt an, dass das Programm login bei einer Änderung des Passworts hierfür das Modul pam_unix.so verwenden soll. (Zu einer Änderung des Passwortes kommt es nur dann, wenn ein auth-Modul festgelegt hat, dass das Passwort geändert werden muss — wenn z.B. ein Shadow-Passwort abgelaufen ist.)

session   required  /lib/security/pam_unix.so

Die achte und letzte Zeile gibt an, dass das Modul pam_unix.so für die Verwaltung der Sitzung verwendet werden soll. Gegenwärtig hat dieses Modul keine Funktion. Es kann durch ein beliebiges notwendiges Modul ersetzt (oder durch Stapeln ergänzt) werden.

Beachten Sie, dass die Reihenfolge der Zeilen in diesen Dateien wichtig ist. Während die Reihenfolge beim Aufrufen von required-Modulen keine große Rolle spielt, ist dies bei den anderen verfügbaren Steuer-Flags sehr wohl der Fall. Das Flag optional wird nur selten verwendet, bei sufficient und requisite ist die Reihenfolge wichtig.

Hier ein Blick auf die auth- Konfigurationsdatei für rlogin:

#%PAM-1.0
auth      required    /lib/security/pam_nologin.so
auth      required    /lib/security/pam_securetty.so
auth      required    /lib/security/pam_env.so
auth      sufficient  /lib/security/pam_rhosts_auth.so
auth      required    /lib/security/pam_stack.so service=system-auth

Erstens überprüft pam_nologin.so, ob /etc/nologin existiert. Ist dies der Fall, kann sich niemand anmelden, mit Ausnahme des Rootbenutzers.

auth      required    /lib/security/pam_securetty.so

Zweitens verhindert pam_securetty.so, dass Root-Anmeldungen auf unsicheren Terminals vorgenommen werden können. Damit werden praktisch alle Root-Anmeldungen über rlogin verhindert. Entfernen Sie diese Zeile, falls Sie entsprechende Anmeldungen zulassen möchten (nur empfehlenswert, wenn entweder keine Verbindung zum Internet besteht oder eine gute Firewall vorhanden ist, siehe unter Abschnitt namens rlogin, rsh, und rexec mit PAM verwenden).

auth      required    /lib/security/pam_env.so

Drittens lädt das pam_env.so Modul die Umgebungsvariablen, die in /etc/security/pam_env.conf spezifiziert sind. .

auth      sufficient  /lib/security/pam_rhosts_auth.so

Viertens: Wenn pam_rhosts_auth.so den Benutzer, der .rhosts in der Benutzer-Home-Dierctory authentifiziert hat, wird rlogin sofort von PAM authentifiziert, ohne das Passwort mit pam_stack.so zu überprüfen. Eine gescheiterte Authentifizierung des Benutzers durch pam_rhosts_auth.so wird ignoriert.

auth      required    /lib/security/pam_stack.so service=system-auth

Fünftens: Wenn die Authentifizierung des Benutzers durch pam_rhosts_auth.so gescheitert ist, führt das pam_stack.so Modul eine normale Passwort-Authentifizierung durch, und erhält das service=system-auth Argument.

	Bitte beachten
	Wenn Sie den Prompt beim Eingeben des Passworts nicht angezeigt haben möchten, nachdem die securetty Prüfung fehlgeschlagen ist, und feststellen, dass ein Benutzer sich als Root anmelden möchte, können Sie das pam_securetty.so Modul von required in requisite ändern. Wenn Sie alternativ Anmeldungen als Root zulassen möchten (was nicht zu empfehlen ist), können Sie diese Zeile auskommentieren.