Pluggable Authentication Modules geben dem Administrator die Freiheit, in jedem PAM-tauglichen Programm beliebige Authentifizierungsverfahren einzusetzen und netzwerkweit einheitliche Benutzerkennungen zu verwenden. Auch die User freut's, sie müssen sich nur noch einen Account merken.
Beim Thema Authentifizieren am Linux-Rechner denken die meisten Admins am ehesten an die Systemdateien »/etc/ passwd« und »/etc/shadow«. Deren Konzept ist so alt wie Unix und erfüllt heute noch seinen Zweck. Inzwischen erledigen Linux-Maschinen aber viele Aufgaben - vom Web-, FTP- oder Fileserver über Mailserver und Proxy bis hin zum CVS-Server -, die ebenfalls ihre Benutzer authentifizieren müssen. Häufig bringen diese Dienste ihre eigene Userverwaltung mit. Allerdings verlieren Admins schnell den Überblick und die Anwender das Verständnis, wenn jeder Dienst eine eigene Benutzername-Passwort-Kombination verlangt.
Zu dieser Entwicklung gesellen sich weitere Neuerungen: Die Tastatur hat ihre Rolle als alleiniges Eingabemedium für die Zugangskennung verloren. Chipkarten, biometrische Merkmale oder Zertifikate auf einem USB-Stick kommen vermehrt zum Einsatz. Manche Systembetreiber möchten einen Login nur zu bestimmten Zeiten erlauben. Auch für das Mounten des Homeverzeichnisses kann eine Authentifizierung nötig sein.
Mit diesen Aufgaben ist das herkömmliche System überfordert: Wenn sich jede Anwendung selbst um Identifizierung und Authentifizierung ihrer Nutzer kümmert, steigt der Programmieraufwand unnötig. Für jede neue Authentifizierungsmethode muss jedes Programm (im Sourcecode) angepasst werden. Mögliche Fehler im Login-Verfahren sind in jedem Programm zu beheben - Anwendungsentwickler kümmern sich aber selten um Neuerungen und Hintergründe der Sicherheitstechniken.
PAM lagert daher die Authentifizierung in eine modulare Bibliothek aus. Vorteil: Die Anwendung muss sich nicht mehr um diese Aufgaben kümmern. Neue Verfahren lassen sich einbinden, ohne die Applikation zu ändern. Auch ist die Konfiguration einheitlich - egal ob Konsolen- oder X11-Login, Telnet, FTP oder SSH. PAM kann sogar mehr als die klassische Passwortdatei-Variante. Neben dem Authentication-Management übernimmt es auch das Account-, Session- und Password-Management.
Da die PAM-Bibliothek jedoch keine Mechanismen besitzt, um Benutzereingaben oder Authentifizierungs-Token entgegenzunehmen, muss sich die Applikation darum kümmern. Nur die Applikation selbst weiß, auf welchem Weg sie zu diesen Daten kommt. Das Lesen von der Rechnerkonsole, aus einer Netzwerkverbindung oder vom Displaymanager-Login implementieren die jeweiligen Programme sowieso.
Eine wichtige Einschränkung hat PAM jedoch: Es ist rein passiv und muss immer von einer Applikation aufgerufen werden. PAM kann den Benutzer daher nicht automatisch einloggen, wenn er seine Chipkarte einsteckt oder den Finger auf einen biometrischen Leser legt. Erst muss die Applikation aktiv werden und PAM anstoßen.
Die schematische Darstellung in Abbildung 1 zeigt, wie der Kommunikationsfluss zwischen Applikation und PAM funktioniert. Jedes Programm lädt bei Bedarf die PAM-Bibliothek. Diese Library wiederum greift auf PAM-Module zurück. Jede Applikation kann ihre eigene PAM-Konfiguration erhalten. Das PAM-Modul kommuniziert mit der PAM-Bibliothek, um seine Parameter auszulesen, und mit der Applikation, um an die Benutzerdaten wie Accountname und Passwort zu gelangen. Manche Module greifen zudem auf vorhandene Dienste zu oder lesen typische Unix-Dateien wie »/etc/passwd«.
Abbildung 1: Das Programm P (rechts) authentifiziert seine Benutzer mit Hilfe der PAM-Bibliothek (Mitte). Diese Library liest ihre Konfigurationsdatei (links), lädt die dort aufgeführten Module und greift bei Bedarf auf weitere Dienste wie Samba oder LDAP zu (unten).
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
