| PAM - Pluggable Authentication Modules | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Inhalt Das Problem Was ist PAM? Nutzung von PAM Fallbeispiel
|
Es gibt auf UNIX-Rechnern verschiedene Services, die in der einen oder anderen Weise Zugang zu dem entsprechendem System ermöglichen (dies gilt natürlich nicht nur für UNIX-Systeme, aber ich möchte mich im folgenden auf UNIX und ähnliche Systeme, insbesondere das fantastische Linux beschränken). Beispiele dafür sind z.B. der ftp-Dämon und der telnet-Dämon. Diese sogenannten system-entry Services müssen nun normalerweise vor Gewährung der eigentlichen Dienste bzw. dem Verschaffen von Systemzugang feststellen, wer der Benutzer ist und ob diesem Benutzer Zugang oder Service gewährt werden kann. Die Feststellung des Benutzers erfolgt dabei normalerweise so, daß der Benutzer gefragt wird, wer er zu sein vorgibt und danach z.B. mittels Paßwortabfrage überprüft wird, ob das wirklich der Fall ist. In UNIX erfolgt diese Identifikation und Authentifizierung traditionell über den passwd-Mechanismus. Also über die Datei /etc/passwd und entsprechende shadow-Dateien. Jede einzelne Anwendung, wie die schon angeprochenen Dämons für ftp und telnet, mußte nun bisher die entsprechenden Mechanismen implementieren. Es ist wohl offensichtlich, daß bei mehrfacher Implementierung der gleichen Sache auch die Fehleranfälligkeit steigt! Außerdem gibt es Probleme, wenn der zugrunde liegende Authenifizierungmechanismus geändert werden soll. Dann ist normalerweise ein Austausch der Applikation bzw. eine Änderung des Quellcodes, ein Neuübersetzen und Installieren notwendig. Ein Beispiel dafür ist z.B. der Austausch des Paßwort-Mechanismus gegen ein Chipkarten-basiertes oder ein biometrische Verfahren (Fingerabdruck, Gesichtserkennung etc.). In besonders sicherheitssensitiven Bereichen könnte das allein evtl. noch nicht ausreichend sein und die Anforderung bestehen, mehrere Verfahren (alternativ oder hintereinander) zu benutzen. Desweiteren erscheint es wünschenswert, in heterogenen Umgebungen nur jeweils eine Benutzerverwaltung aufzubauen bzw. zu pflegen und diese dann unter allen Systemen nutzen zu können. Zusammengefaßt hier noch einmal die Hauptnachteile der bisherigen Lösung:
Um die oben beschriebenen Nachteile zu beheben, wurde nun das sogenannte PAM-Framework entwickelt. PAM trennt die einzelnen Anwendung von den Mechanismen zur Benutzerauthentifizierung. Dabei steht PAM für Plaggable Authentication Modules. Der Name deutet dabei schon die Möglichkeiten zur Verwendung von unterschiedlichen Modulen (Modules) zur Authentifikation (Authentication) und eine hohe Konfigurierbarkeit (Pluggable) der Gesamtlösung durch den System-Administrator an. Das PAM-Framework ist ein Set von Shared Libraries. Die Module liegen ebenfalls als Shared Libraries vor und implementieren jeweils einen bestimmten Mechanismus. Der Administrator kann nun (abhängig vom Sicherheitsbedürfnis, Umgebung, persönlichen Vorlieben etc.) für jede einzelne Anwendung festlegen, welche Mechanismen zum Einsatz kommen sollen (d.h. also welche Module verwendet werden). Dabei könne auch mehrer Module hintereinander zum Einsatz kommen (-> Module-Stacking) und durch die Verwendung mehrer Authentifizierungsmechanismen ein Unified-Login für den Benutzer erreicht werden. Wie Module, Framework und Applikationen zusammenarbeiten verdeutlicht (hoffentlich) noch einmal das folgende Bild:
Neben dem:
werden auch noch die folgenden Management-Aufgaben von PAM abgedeckt:
Das Ganze wird ebenfalls über Module abgewickelt. Jedes PAM-Modul muß mindestens einen, kann aber auch mehrere dieser Management-Tasks abdecken. An dieser Stelle noch ein paar historische Daten: PAM wurde ursprünglich von der Firma Sun für ihr UNIX-Derivat Sun Solaris entwickelt. 1995 wurde das Ganze in der RFC 86.0 der Open Software Foundation (OSF) veröffentlicht. Seitdem wird diese Technologie auch schrittweise in anderen UNIX-Systeme eingeführt (beispielsweise in Hewlett-Packard's HP-UX seit Version 10.20). Schon seit geraumer Zeit gibt es das Projekt Linux-PAM, das sich zur Aufgabe gemacht hat, ein freies PAM speziell für Linux aber auch für andere Systeme zu entwickeln. Ergebnisse liegen schon vor und sind auch schon in die meisten Linux-Distributionen eingeflossen (z.B. SuSE-Linux ab Version 6.1). Mit der Linux-üblichen Dynamik sind auch schon sehr viele Module und PAM-enabled'te Anwendungen verfügbar. Für die Zukunft scheint PAM eine wichtige Rolle für ein Single Sign-On zu übernehmen. Ein entsprechender Spec-Entwurf der X/OPEN liegt als X/OPEN Single Sign-On Service (XSSO) liegt bereits vor! PAM aus Sicht des Systemadministrators Die folgenden Beispiele und Hinweise sind Linux-PAM-spezifisch. Obwohl sich andere Systeme / PAM-Implementierungen größtenteils analog verhalten sollten, kann es doch an der einen oder anderen Stelle kleinere oder größere Unterschiede zu geben. Erster Anlaufpunkt für entsprechende Probleme sollte also die zum jeweiligen System gelieferte Dokumentation sein! Der Systemadministrator konfiguriert das PAM-Framework über ein oder mehrere Konfigurationsdateien. Bei der älteren Variante kommt eine zentrale Konfigurationsdatei /etc/pam.conf zum Einsatz, die wie folgt aufgebaut ist:
Der module-type spiegelt die zu übernehmende Management-Aufgabe wieder, während das control-flag angibt, wie im Falle eines fehlerhaft oder korrekt abgearbeiteten Moduls weiter vorgegangen wird. Es wird dabei folgendermaßen verfahren:
Generell werden die Module der Reihe nach, also von oben nach unten abgearbeitet. Wird der Pfad zum Modul nicht als absoluter Pfad angegeben, gilt er relativ zu /lib/security. Für die neuere Konfigurationsvariante existiert ein Verzeichnis /etc/pam.d und in diesem Verzeichnis für jede PAM-fähige Anwendung eine eigene Konfigurationsdatei, die normalerweise den gleichen Namen wie die Anwendung oder des gewährten Services trägt. Der Aufbau der einzelnen Dateien ist bis auf die (nicht notwendige) Spalte service-name genauso wie die oben beschriebene zentrale Konfigurationsdatei /etc/pam.conf. Vorteil dieser Variante ist die bessere Übersichtlichkeit und ein vereinfachtest Packaging von Anwendungen. Im folgenden 2 kleine Beispiele für Konfigurationsdateien der neueren Art und Syntax aus einem Linux-System:
Module für Linux-PAM gibt es wie schon angesprochen relativ viele (mit steigender Tendenz). Hier noch einige wichtige, die auch typisch für die Authentifizierung sind und zum Teil recht interessante Lösungen gestatten:
Weniger typisch sind dann Module wie:
Hier noch eine Auswahl von Anwendungen mit PAM-Unterstützung:
PAM aus Sicht des Anwendungsentwicklers Der Anwendungentwickler benutzt die folgenden beiden PAM-Include-Files:
und die Libraries pam, pam_misc und dl. Bei der Compilierung also:
Die Anwendung benutzt die Funktionen:
Wichtig ist, daß die Anwendung der PAM-Library eine Funktion zur Kommunikation mit dem Benutzer zur Verfügung stellt (-> pam_conv(..)), damit PAM z.B. den Benutzernamen und das Paßwort des Users abfragen kann. PAM aus Sicht des Modulentwicklers Ein Entwickler von Modulen includiert:
Außerdem definiert er je nach zu implementierender Funktionalität die folgenden symbolischen Präprozessor-Konstanten:
und implementiert dementsprechend diese Funktionen:
Analog zum Anwendungsentwickler bindet auch er die Libraries pam, pam_misc und dl ein. Die Ergebnisse der Arbeit des Modulentwicklers, also die fertigen Module werden dann in das Verzeichnis /lib/security kopiert und können dann benutzt werden. Beispiel PPP-Einwahlrechner: Es gibt bereits eine funktionierende WindowsNT-Struktur (Domäne INFLB1). Als Einwahlrechner für den externen Inter- und Intranet-Zugriff sollen aus verschiedenen Gründen Linux-Rechner zum Einsatz kommen. Nun wäre es unsinnig extra deswegen eine eine zweite Benutzerverwaltung aufzubauen. Man könnte also zur Authentifikation einen existierenden WindowsNT-PDC (Primary Domain Controller) benutzen. Ein dafür geeignetes Modul ist pam_smb. Da die Einwahl über den ppp-Dämon erfolgen soll, wird eine Datei /etc/pam.d/ppp angelegt:
Es wird also SMB zur Auth. eingesetzt, wobei der angegebene Parameter bestimmt, daß der Benutzer nicht als lokaler User auf dem Linux-System existieren muß. Das Modul pam_permit hat implementiert keine Funktionalität, sondern beendet nur mit positivem Returnwert. Damit pam_smb weiß, gegen welche Windows-Maschine/Domäne der User authentifiziert werden soll, ist noch eine weitere Konfigurationsdatei (/etc/pam_smb.conf) erforderlich:
Die "normale" Linux"-Nutzerverwaltung wird also für die PPP-Einwahl komplett umgangen. Zur Ausarbeitung dieser Webseite bzw. des zugehörigen Vortrages habe ich mich der folgenden Literatur bedient:
Im Internet kann man die gesamte Literatur auf der Homepage des Linux-PAM-Projektes finden: Wenn sich nun jemand fragt wieso diese Seite entstanden ist und wer das hier verbrochen hat, hier kommt die Antwort: Mein Name ist Geralf Bähr (e-mail: htw7208@informatik.htw-dresden.de) und ich studiere (derzeit im 7. Semester) an der Hochschule für Technik und Wirtschaft Dresden (FH) Allgemeine Informatik. Diese Seite ist Teil eines Vortrages im Fach Betriebssysteme III. Das Thema das Vortrages war dabei frei wählbar. Und ich habe PAM ausgewählt, da ich mich kurze Zeit vorher aufgrund eines kleinen Problemes mit meinem Linux-System zu Hause etwas mit der Materie befasst habe. Wer sich für die Orginal-Präsentation interessiert findet Sie hier als:
Eine nichtkommerzielle Nachnutzung dieser Seiten gleich welcher Art ist ausdrücklich gestattet. Anregungen, Hinweise, Bugmeldungen u.ä. können gerne an meine obige e-mail-Adresse geschickt werden.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
