Die Pluggable Authentication Modules, kurz PAM, erlauben auf vielfältige Weise die Authentifizierung am System – etwa per Fingerabdruck.

Das neue Notebook mit dem schicken Fingerprint-Reader ist endlich da – doch wie benutzen Sie diese nützliche Hardware-Komponente unter Linux zum Authentifizieren von Benutzern? Hier helfen die Pluggable Authentication Modules (PAM) weiter. Sie ermöglichen es, Anwender über eine Vielzahl von unterschiedlichen Verfahren zu authentifizieren.

Standards

Die klassische Benutzerauthentifizierung erfolgt meist mithilfe der Dateien /etc/passwd und /etc/shadow. Für jeden bekannten Anwender steht in der Datei /etc/passwd ein Eintrag mit den Account-Informationen, wie etwa dessen User- und Gruppen-ID sowie Login-Shell und Heimatverzeichnis (Listing 1).

Bei jeder Anmeldung ermittelt PAM die Prüfsumme des vom Benutzer eingegebenen Passworts und vergleicht sie mit der in der Datei /etc/shadow hinterlegten. Stimmen beide überein, gilt der Benutzer als korrekt authentifiziert. Anderenfalls erscheint einen Fehlermeldung, und die Anmeldung des Benutzers schlägt fehl.

# <grep foo /etc/passwd /etc/shadow
/etc/passwd:foo:x:503:503::/home/foo:/bin/bash
/etc/shadow:foo:$1$svDhI9rq$4Te4c14ODcwP.GqZeeTAA/:14305:0:99999:7:::

Verschiedene Module

Für andere Arten der Benutzeranmeldung, beispielsweise über einen LDAP-Server oder über eine Chipkarte, müssten die Entwickler alle bestehenden Anwendungen neu schreiben, um die neue Form der Authentifizierung zu unterstützen. Das lässt sich freilich in der Praxis kaum realisieren. Hier hilft PAM mit einer Art Framework zur Authentifizierung von Benutzern: Jede Anwendung, die mit PAM zusammenarbeitet, besitzt unterhalb das Verzeichnisses /etc/pam.d/ eine eigene Konfigurationsdatei. Über diese ruft das Programm sogenannte PAM-Bibliotheken, auch PAM-Module genannt, aus dem Verzeichnis /lib/security/ auf.

Jedes dieser Module übernimmt eine bestimmte Aufgabe. So dient pam_unix.so zur klassischen Benutzerauthentifizierung via /etc/passwd und NIS (Network Information Service). Das Modul pam_ldap.so ermöglicht das Authentifizieren über LDAP-Server, pam_thinkfinger.so unterstützt die Benutzeranmeldung via Fingerprint-Reader. Möchten Sie eine neue Art der Authentifizierung hinzufügen, so reicht es aus, die jeweilige PAM-Bibliothek in der passenden Konfigurationsdatei anzugeben. Anstatt für jede neue Art der Authentifizierung die Anwendung neu zu schreiben, müssen sie diese nur einmalig “pamifizieren”, indem Sie beim Übersetzen aus den Quellen auf die Bibliothek libpam.so zurückgreifen.

Neben der Authentifizierung von Benutzern kümmert sich PAM auch um die Autorisierung. So lässt sich die Benutzeranmeldung etwa auf bestimmte Uhrzeiten einschränken. Mit anderen Modulen bestimmen Sie, wie viel CPU-Rechenzeit ein Benutzer für seine Login-Sitzung bekommt – gerade in Zeiten von SETI@home und ähnlichen Projekten ein interessantes Feature.

Schließlich kümmert sich PAM auch um die Qualität der Passwörter, indem es beim Erstellen oder Ändern definierte Komplexitätsregeln auf diese anwendet. So legen Sie via PAM zum Beispiel fest, wie viele Klein- oder Großbuchstaben ein neues Passwort enthalten muss, damit es das System als gültiges Passwort anerkennt.

Grundlagen

Bevor wir uns die Konfiguration von PAM ansehen, ist jedoch noch etwas Theorie notwendig, um seine Funktionsweise zu verstehen. Wie bereits erwähnt besitzt jedes Programm, das mit PAM zusammenarbeitet, eine eigene Konfigurationsdatei im Verzeichnis /etc/pam.d/. Eine solche Datei enthält jeweils vier Sektionen:

• auth – Authentifizierung von Benutzern
• account – Autorisierung von Benutzern
• password – Erzwingen einer bestimmten Passwort-Komplexität
• session – Überwachen der Sitzung eines Benutzers

In jeder dieser Sektionen lassen sich nun die notwendigen PAM-Bibliotheken aufrufen. Unter /usr/share/doc/pam-version/txts/ finden Sie eine ausführliche Hilfe zu den meisten PAM-Bibliotheken. Der Aufruf der Bibliotheken erfordert jeweils die Angabe so genannter Kontroll-Flags. Diese bestimmen das Verhalten im Fehlerfall. PAM kennt dazu die folgenden Flags:

• required: Vorgeschrieben – die Bibliothek muss erfolgreich durchlaufen, ansonsten wird ein Fehler zurückgegeben ohne den Vorgang unmittelbar abzubrechen.
• requisite: Erforderlich – muss die Bibliothek ebenfalls erfolgreich durchlaufen; im Fehlerfall bricht der Vorgang aber unmittelbar ab.
• sufficient: Ausreichend – das aufrufende Programm bekommt ohne Berücksichtigung von Fehlern unmittelbar eine Erfolgsmeldung zurückgeliefert.
• optional: wahlweise – Erfolg oder Fehler bleiben ohne Auswirkungen.
• include: Einschließlich – erlaubt das Einlesen von Bibliotheken aus anderen Dateien.

Das Beispiel in Listing 2 zeigt eine einfache PAM-Konfiguration für die auth-Sektion des Programms login.

auth    required        pam_securetty.so
auth    required        pam_env.so
auth    sufficient      pam_unix.so
auth    required        pam_deny.so

Das erste Modul pam_securetty.so prüft, ob sich der Benutzer root über ein sicheres Terminal anmeldet. Als solche gelten die in der Datei /etc/securetty aufgeführten. Wegen des gesetzten Kontroll-Flags required muss dieser Test erfolgreich verlaufen. Versucht root sich über ein unsicheres Terminal wie Telnet anzumelden, so misslingt das Login.

Die Konfigurationsdatei des nächste Moduls pam_env.so heißt /etc/security/pam_env.conf. Über diese setzten Sie bestimmte Login-Variablen. Auch hier setzt das gesetzte Kontroll-Flag required das Erfüllen aller angegebenen Bedingungen für ein Login voraus.

Der Eintrag der dritten Zeile lädt schließlich das eigentliche Modul zur Authentifizierung von Benutzern, pam_unix.so. PAM vergleicht Benutzername und Passwort-Prüfsumme mit den Einträgen in den Dateien /etc/passwd und /etc/shadow. Stimmen diese überein, liefert PAM ein abschließendes OK an das Login-Programm zurück: Der Benutzer ist damit erfolgreich authentifiziert. Doch halt: Als Kontroll-Flag steht hier sufficient – das heißt, fehlerhafte Eingaben ignoriert PAM und fährt einfach mit der nächsten Bibliothek fort.

Glücklicherweise handelt es sich dabei um pam_deny.so. Dieses Modul liefert immer den Wert Nicht OK zurück und erfüllt damit eine vergleichbare Funktion wie die abschließende Firewall-Regel DENY ALL. Da im Beispiel das Kontroll-Flag required gesetzt ist, schlägt die Anmeldung des Benutzers bei Erreichen dieser Stelle grundsätzlich fehl.

Nun fragen Sie sich vielleicht: Wieso verwendet man beipam_unix.so nicht direkt required als Kontroll-Flag und spart sich die letzte Regel? Es existieren eine Vielzahl unterschiedlicher Authentifizierungsmodulen, die man der Reihe nach abarbeiten kann. Liegt das Benutzerkonto beispielsweise nicht lokal vor, sondern auf einem LDAP-Server, so könnte die PAM-Konfiguration wie in Listing 3 aussehen.

auth    required        pam_securetty.so
auth    required        pam_env.so
auth    sufficient      pam_unix.so
auth    sufficient      pam_ldap.so use_first_pass
auth    required        pam_deny.so

Bemerken Sie den Unterschied? Nach pam_unix.so folgt ein weiteres Authentifizierungsmodul namens pam_ldap.so. Klappt also die lokale Anmeldung nicht, fährt die Prozedur wegen des gesetzten Kontroll-Flags sufficient mit dem nächsten Modul pam_ldap.so fort und versucht es über einen LDAP-Server. Das Argument use_first_pass sorgt dafür, das der Benutzer sein Passwort nicht noch einmal neu eingeben muss: PAM greift einfach auf das Passwort vom ersten Anmeldeversuch zurück. Klappt die Anmeldung via LDAP, so liefert PAM wieder ein abschließendes OK zurück. Ansonsten geht es mit pam_deny.so weiter, das ein Nicht OK liefert und somit für einen Login-Fehler sorgt.

Fingerprints

Der eingangs erwähnte, schicke Fingerprint-Reader wartet immer noch darauf, dass Sie ihn zum Leben erwecken. Dazu laden Sie via Sourceforge das dafür geeignete PAM-Modul [2] herunter und installieren es mit dem klassischen Dreisatz ./configure && make && sudo make install. Unter Fedora greifen Sie via Yum auf das Software-Repository zurück und installiert das Modul mit dem Aufruf yum install thinkfinger.

Nach der Installation findet sich im Order /lib/security/ das neue PAM-Modul pam_thinkfinger.so. Bevor Sie es in die PAM-Konfiguration einbinden, sollten Sie es erst erst einmal auf korrekte Funktionsweise testen. Laut Dokumentation arbeitet es Modul problemlos mit dem Fingerprint-Reader von UPEK/SGS Thomson Microelectronics zusammen, den die meisten aktuellen Lenovo-Notebooks verwenden (Abbildung 1). Über die Anwendung tf-tool lesen Sie zu Testzwecken einen Fingerabdruck ein und verifizieren ihn anschließend (Listing 4, erster und zweiter Aufruf).

Abbildung 1: Für die Fingerprint-Reader der bei Linux-Anwendern besonders beliebten IBM/Lenovo-Thinkpads gibt es das PAM-Modul Thinkfinger.

# tf-tool --acquire
ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>
Initializing… done.
Please swipe your finger (successful swipes 3/3, failed swipes: 0)… done.
Storing data (/tmp/test.bir)… done.
# tf-tool --verify
ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>
Initializing… done.
Please swipe your finger (successful swipes 1/1, failed swipes: 0)… done.
Result: Fingerprint does match.
# tf-tool --add-user foo
ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>
Initializing… done.
Please swipe your finger (successful swipes 3/3, failed swipes: 0)… done.
Storing data (/etc/pam_thinkfinger/foo.bir)… done.
Setting ACL on aquired file: /etc/pam_thinkfinger/foo.bir.

Erkennt die Software den Fingerabdruck nicht, erscheint als Ergebnis Fingerprint does *not* match. Die ersten Versuche können durchaus fehlschlagen, da Sie sich erst einmal an die Funktionsweise des Gerätes gewöhnen müssen. Ziehen Sie beispielsweise den Finger zu schnell oder zu langsam über das Lesefeld, wird der Abdruck nicht erkannt. Klappt schließlich alles, erzeugen Sie einen individuellen Fingerabdruck auf dem System (Listing 4, dritter Aufruf). Diesen speichert das Programm in einer Datei unterhalb von /etc/pam_thinkfinger/. Möchten Sie sich die gespeicherten Fingerabdrücke einmal als Grafik anzeigen lassen, verwenden Sie dafür die Gnome-Anwendung Fprint ([3], Abbildung 2). Das Tool unterstützt jedoch nicht alle Fingerprint-Reader.

Abbildung 2: Das Programm Fprint zeigt den gespeicherten Fingerabdruck eines Anwenders an.

PAM anpassen

Nach Abschluss der Vorbereitungen gilt es, PAM für die Authentifizierung per Fingerprint einzurichten. Je nach Distribution müssen Sie dazu andere Dateien bearbeiten; deren Inhalt fällt in den meisten Fällen jedoch nahezu identisch aus. Möchten Sie die Authentifizierung über den Fingerprint-Reader als erstes vornehmen, binden Sie das Modul pam_thinkfinger.so vor pam_unix.so ein.

Damit PAM nach der erfolgreichen Authentifizierung über den Fingerabdruck nicht noch einmal das Passwort abfragt, setzen Sie das Kontroll-Flag sufficient, das bei erfolgreicher Anmeldung keine weiteren Bibliotheken aufruft und die Anmeldung somit erfolgreich abschließt. Sollte das Login über den Fingerabdruck nicht funktionieren, springt sozusagen als Notlösung pam_unix.so ein und fragt den Benutzer nach seinem Passwort.

Nun wäre es allerdings recht umständlich, wenn Sie für alle Programme die notwendigen PAM-Module in jeder einzelnen PAM-Konfiguration manuell eintragen müssten. Hier hilft eine Art zentrale PAM-Konfigurationsdatei: Unter Fedora heißt sie /etc/pam.d/system-auth, einige andere Linux-Distributionen verwenden dafür /etc/pam/common-auth. In dieser Datei tragen Sie sämtliche PAM-Module ein, die Sie zur Authentifizierung verwenden. Das Kontroll-Flag include erlaubt das Einbinden in allen anderen PAM-Konfigurationen, sodass allen Programmen die PAM-Bibliotheken aus der zentralen Konfigurationsdatei zur Verfügung stehen. Listing 5 und Listing 6 zeigen die Einträge für die Dateien /etc/pam.d/login und /etc/pam.d/system-auth.

# /etc/pam.d/login
auth    required        pam_securetty.so
auth    include system-auth

# /etc/pam.d/system-auth
auth    required        pam_env.so
auth    sufficient      pam_thinkfinger.so
auth    sufficient      pam_unix.so
auth    required        pam_deny.so

Da die meisten PAM-Konfigurationen die zentral verwaltete PAM-Konfiguration mittels include einbinden, steht nun auch das PAM-Modul für den Fingerprint-Reader für alle Programme bereit, die PAM zur Authentifizierung verwenden. Beispielsweise klappt eine Authentifizierung mittels su oder einer grafischen Anwendung (Abbildung 3) nun auch mittels Fingerabdruck.

Abbildung 3: Auch grafische Anwendungen erkennen dank PAM den Benutzer anhand seines Fingerabdrucks.

Erweiterungen

Wie schon erwähnt, beherrscht PAM nicht nur die Benutzerauthentifizierung, sondern kann noch viel mehr. Wollen Sie beispielsweise Benutzern nur zu einer bestimmten Uhrzeit den Zugang zum System erlauben, verwenden Sie das Modul pam_time.so. Sie binden es genau wie pam_thinkfinger.so in der zentralen Datei /etc/pam.d/system-auth (bzw. common-auth) ein. Da es sich hier jedoch um ein Modul zur Autorisierung anstatt zur Authentifizierung handelt, tragen Sie es in der Sektion account ein. Über die Steuerdatei /etc/security/time.conf konfigurieren Sie es. Möchten Sie beispielsweise den Zugang zum SSH-Server in der Nacht verbieten, erledigen Sie das mit dem Eintrag sshd;*;*;!Al2100-0600. Die Abkürzung Al steht für alle Tage der Woche; eine genaue Beschreibung der Syntax steht in der Konfigurationsdatei.

Ein weiteres interessantes Modul, diesmal für die password-Sektion von PAM, ist pam_cracklib.so. Mit ihm setzten Sie eine strenge Passwort-Policy durch. Da es keine eigene Konfigurationsdatei besitzt, konfigurieren Sie das Modul durch das Anhängen von Argumenten in der Sektion passwort. Damit ein Benutzer bei jeder Passwortänderung mindestens zwei Sonderzeichen in das neue Passwort einbauen muss, wählen Sie als Argument ocredit=2. Für drei Zahlen, die im Passwort vorkommen müssen, lautet es dcredit=3. Die komplette Liste aller Argumente finden Sie in der PAM-Dokumentation.

Mit dem Modul pam_limits.so setzen Sie gewisse Ressourcenbeschränkungen durch. Sie rufen es in der PAM-Sektion session auf und konfigurieren es über /etc/security/limits.conf. Möchten Sie beispielsweise dem Benutzer foo nur das Ausführen von zehn parallelen Prozessen erlauben, so sieht die Konfiguration dafür wie in Listing 8 aus. Der Befehl ulimit -u zeigt das gesetzte Limit an, das der Benutzer mit ulimit -u Zahl_der_Prozesse bis zum Hard-Limit selbständig erhöhen kann.

foo     soft    nproc   10
foo     hard    nproc   15

Sie sehen also, mit PAM lassen sich jede Menge interessante Dinge anstellen [4]. Fehlen Module in Ihrer Distribution, finden Sie bei Kernel.org [5] eine große Auswahl zusätzlicher PAM-Module.