Pluggable Authentication Modules

Dieser Artikel widmet sich der Plugin-gestützten Sicherheitsbibliothek PAM, ihrer Konfiguration und einige praktischen Beispielen, wo man PAM wie auf gekonnte Weise einsetzen kann.

Einleitung

PAM kommt auf allen modernen Unix-Systemen zum Einsatz. Das Prinzip ist recht einfach:

• Ein Programm wird für die Anmeldung von Benutzern eingesetzt ( login , ssh , diverse Display-Manager, POP3-Server, ... - die Liste ist endlos).
• Natürlich könnte man in jedes Programm fest eincodieren, dass es zur Authentifikation bestimmte Methoden zuläßt (z.B. die klassische Unix-Authentifikation per /etc/passwd . Da wir in einer vernetzten Welt leben, sollte man sich auch per nis authentifizieren können. Manche wollen jedoch lieber ldap, andere hesiod - die Sun-Fans wollen nisplus - und schon wird's unübersichtlich, da alle diese Methoden dann in jedes Programm integriert werden müßten, das eine Authentifikation durchführen will.
• Man führt eine Zwischenschicht ein, die zwischen den verschiedenen Authentifikationsmethoden und den Programmen, die Authentifikation anbieten sollen vermittelt. Das geschieht in Form eine Library, die von den Programmen gelinkt wird und die dynamisch Plugins (sog. PAM-Module) nachladen kann.
• An zentraler Stelle ( /etc/pam.d/ ) stellt man nun für die einzelnen Programme ein, auf welche Methode sie Authentifikationen akzeptieren sollen. Dort liegt dann für jedes Programm ein sog. PAM-Stack - also ein Authentifikations-Konfigurationsfile.
  Hinweis: Früher waren sämmtliche PAM-Stacks in einer Konfigurationsdatei zusammengefasst ( /etc/pam.conf ). Das ist jedoch völig unpraktisch, da ein Softwarepaket wie z.B. ssh an einer zentralen Konfigurationsdatei herumbasteln müsste, anstelle einfach eine Datei in ein Verzeichnis ( /etc/pam.d ) zu legen.

Was kann PAM alles?

PAM kann ...

• ... von verschiedenstenen Diensten benutzt werden, um Benutzer-Zugangsdaten zu testen. Dienste sind z.B. der login -Prozess oder ein X-Display-Manager wie kdm .
• ... einen Namen und ein Passwort entgegennehmen und dazu Ja oder Nein sagen.
  • Es kann auch differenziertere Codes zurückgeben - z.B. Der Account läuft bald ab . Diese Codes auszuwerten und an den Benutzer durchzureichen liegt in der Verantwortung des Dienstes, der PAM benutzt.
• ... auch mit mehreren Passwörtern umgehen. Wenn sich ein Nutzer z.B. innerhalb eines PAM-Stacks gegen 3 Benutzerdatenbanken mit unterschiedlichen Passwörtern authentifizieren muss, ist das machbar (Stichwort try_first_pass )
• ... nicht nur den Namen und Passwörter auswerten. Die Plugins haben Zugriff auf folgende Daten:
  • user Der Name des sich einloggenden Benutzers.
  • tty Der (virtuelle) Terminal, über den der Loginvorgang erfolgt.
  • rhost Die Adresse des Rechners, von dem aus der Loginvorgang ausgelöst wurde (sinnvoll, wenn es sich um einen Netzwerkdienst wie ssh handelt).
  • ruser Der Name des Benutzers, der sich gerade versucht, in den sich authentifizierenden Benutzer zu verwandeln . Das ist z.B. bei su sinnvoll, wenn man root das Recht geben will, sich in jeden zu verwandeln.
• ... auf mehrere Arten authentifizieren. Folgendes ist z.B. denkbar:
  • Der Benutzer muss entweder das Passwort eingeben, dass ihm in /etc/passwd zugeordnet ist oder das, welcher im NIS steht.
  • Der Benutzer muss das Passwort eingeben, das in /etc/passwd steht und anschliessend das. was im NIS steht.
  • Der Benutzer muss das Passwort eingeben, das in /etc/passwd steht, was jedoch unbedingt das selbe sein muss, wie das, das im NIS steht.
• ... nicht nur authentifizieren ( auth ). Über passende Plugins kann jede Anwendung auch folgendes machen:
  • password Passwörter ändern
  • account Das Login eines Benutzers autorisieren . Z.B. kann man einem bestimmten Benutzer ausschliesslich zwischen 08:00 und 18:00 auf den Rechner lassen oder alle Benutzer ausser gert und root aussperren.
  • session Andere nützliche Dinge nach der Autorisation tun. Z.B. könnte man die Message of the Day anzeigen lassen oder wichtige Umgebungsvariablen setzen.
• ... grossen Einfluss auf den Login-Vorgang nehmen, da die Plugins im Adressraum des Login-Prozesses ausgeführt werden, der später per exec() durch die Login-Shell oder den Session-Manager ersetzt wird. Damit können z.B.
  • Umgebungsvariablen gesetzt,
  • Files mit Superuserrechten geöffnet,
  • Gruppenmitgliedschaften verändert oder auch
  • extrem spezielle Dinge gemacht werden wie z.B. eine PAG für AFS erzeugen.

Wie wird ein PAM-Stack verarbeitet?

Die Abarbeitung erfolgt für alle 4 Modi von PAM auf die gleiche Weise, wird jedoch hier anhand der Authentifikation beschrieben.

Der PAM-Stack besteht aus Regeln und wird von oben nach unten abgearbeitet - vergleichbar mit einem kleinen Programm. Jede Regel besteht aus einer Zeile der Form

[Modus] [Anweisungen] [zu benutzendes Plugin] [Parameter für das Plugin]

an beliebigen Stellen können zusätzlich Anweisungen der Form

@include [Dateiname]

eingefügt werden. Die Regeln in [Dateiname] werden dann abgearbeitet, als ob sie direkt im jeweiligen PAM-Stack wären.

Der Stack führt zwei internene Zustände mit:

• Der aktuelle Rückgabecode , der definiert, ob nach Abarbeitung der letzten Regel, die den Rückgabecode beeinflußt hat, die Authentifikation geklappt hat oder nicht. Mit Hilfe der [Anweisungen] kann der innere Zustand manipuliert werden. Folgende Rückgabecodes kann der Stack besitzen:
  • undef Dieser ist am Anfang gesetzt (und wenn die Anweisung reset benutzt wird).
  • True Die Authentifikation wird - wenn nichts mehr dazwischenkommt - erfolgreich.
  • False Die Authentifikation wird - wenn nicht noch ein Wunder passiert ( reset -Anweisung ) - nicht erfolgreich sein.
• Die aktuelle abgearbeitete Regel. Auch dieser "Zustand" kann durch Anweisungen beeinflusst werden, was praktisch einem Goto-Befehl entspricht.

Der [Modus] ist je nachdem wofür die Regel benutzt werden soll einer von auth , account , session , password

Anweisungen

Die Anweisungen bestehen aus einem Satz Regeln, die festlegen, was passieren soll, wenn das Plugin welchen Rückgabecode liefert. Dabei kann man auf vorgefertigte Anweisungsregeln zurückgreifen, oder aber selbst Hand anlegen und die Anweisungen feintunen.

Standard-Anweisungsregeln

Eine vordefinierte Regelsätze decken bereits die wichtigsten Anweisungen ab:

• required Der Erfolg des Plugins ist wichtig. Wenn die Authentifikation gegen dieses Plugin nicht klappt, soll der ganze PAM-Stack fehlschlagen - er wird jedoch weiter abgearbeitet.
  Der Regelsatz entspricht: [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
• requisite Das Plugin ist so wichtig, dass der Stack sofort mit einem Fehlschlag beendet werden soll. Weitere Regeln werden nicht abgearbeitet.
  Der Regelsatz entspricht [success=ok new_authtok_reqd=ok ignore=ignore default=die]
• sufficient Wenn die Regel erfolgreich ausgeführt wird, ist die Authentifikation erfolgreich abgeschlossen. Es wird dann keine weitere Regel abgearbeitet.
  Der Regelsatz entspricht [success=done new_authtok_reqd=done default=ignore]
• optional Diese Regel muss nicht unbedingt erfolgreich abgearbeitet werden. Wenn die Regel die einzige im Stack ist, ist ihr Erfolg jedoch ausschlaggebend für die erfolgreiche Abarbeitung des PAM-Stacks.
  Der Regelsatz entspricht [success=ok new_authtok_reqd=ok default=ignore]

Anweisungsregeln selbstgebaut

Der Anweisungsblock kann stat aus einem Einzelnen reservierten Wort auch aus einem Block der Form

[result1=command1,result2=command2,...]

bestehen. Dabei steht ein result für einen möglichen Rückgabecode des Plugins in der PAM-Stack-Regel. command ist eine der folgenden Anweisungen:

• ignore Der Rückgabecode des Plugins wird ignoriert.
• bad Die Rückgabecode des PAM-Stacks wird auf False gesetzt. Wenn das die letzte Regel des Stacks ist, dann geht die Authentifikation schief.
• die Der PAM-Stack wird beendet - die Authentifikation ist nicht erfolgreich.
• ok Wenn der Rückgabecode des PAM-Stacks nicht False ist, wird der Rückgabecode des _PAM-Stacks auf True gesetzt.
• done Der PAM-Stack wird beendet. Wenn der Rückgabecode des PAM-Stacks nicht False ist, hat die Authentifizierung geklapt.
  *Hinweise: *
  • Wenn der Rückgabecode doch False ist, kann mit folgender vorgeschalteter Regel dafür sorgen, dass das done trotzdem zu einer erfolgreichen Authentifikation führt:
    auth [default=reset] pam_permit.so
• reset Der Rückgabecode des PAM-Stacks wird auf undef gesetzt, anschliessend geht's bei der nächsten Regel im Stack weiter.

Standard-Plugins

Eine stattliche Anzahl von Standard-Plugins steht bereit, um z.B. die Authentifikation gegen /etc/passwd und nis durchzuführen und auch diverse spezielle Plugins, die nicht direkt einen Authentifikationsdienst ansprechen. Die Plugins sollen hier im einzelnen beschrieben werden.

Plugins liegen per default in /lib/security und passen entsprechende dem Globber-Ausdruck pam_*.so . Jedes Plugin kann Funktionen für einen oder mehrere der PAM-Modi bereitstellen.

pam_permit.so - Garantierter Erfolg

Dieses Plugin liefert (fast) immer success zurück.

Hinweis:

• Es gibt eine kleine Einschränkung. Ist der sich authentifizierende User nicht definiert, schlägt sogar pam_permit.so fehl.
• Existiert der Benutzer nicht, liefert dieses Plugin =user_unknown_ zurück.

Beispiele:

• Diese Zeilen in Kombination führen immer sofort zur erfolgreichen Authentifikation:
  auth [default=reset] pam_permit.so
auth [default=done] pam_permit.so
• Alternativ kann man auch diese einzelne Zeile ganz an den Stackanfang setzen:
  auth [default=done] pam_permit.so

pam_deny.so - Gewollter Fehlschlag

Dieses Plugin liefert immer einen Fehlschlag (also = success zurück).

pam_nologin.so

Dieses Plugin liefert nur dann success , wenn eine oder mehrere der folgenden Bedingungen wahr sind:

• Normale benutzer dürfen sich einloggen (= /etc/nologin existiert nicht ). Das wird meist benutzt, um Benutzer vom System ferzuhalten, während es bootet.
• Der sich einloggende Benutzer ist root .

pam_listfile.so

Dieses Plugin testet, ob ein Benutzer in einer Liste vorkommt, die sich Zeilenweise in einer Datei befindet.

Parameter:

• file=[File] Die Liste, gegen die verglichen werden soll, befindet sich in der Datei [File] .
• sense=[Modus] Damit wird festgelegt, wie das Modul reagieren soll, wenn der Benutzer (genauer: das item ) in der angegebenen Datei gefunden wird. Mögliche Werte für [Modus] sind:
  • allow Wer gefunden wird, darf rein.
  • deny Wer gefunden wird, bleibt draussen.
• item=[Feld] Damit legt man fest, welche Information in der Liste gesucht werden soll. Möglich sind folgende:
  • user , rhost , tty , ruser (Was das bedeutet - siehe hier)
  • group Die Gruppen, in denen der neue Benutzer Mitglied ist.
  • shell Die Default-Shell des sich authentifizierenden Benutzers.
• onerr=[Modus] definiert, was im Fehlerfall (Bsp: Datei kann nicht gelesen werden) passieren soll
  • succeed Im Fehlerfall liefert das Plugin success zurück.
  • fail Im Fehlerfall liefert das Plugin service_err zurück.
• quiet Wenn dieser Parameter angegeben ist, werden keine Fehler im Plugin (z.B. Datei nicht gefunden) ans Syslog gemeldet.

pam_localuser.so

Dieses auth -Plugin testet, ob der aktuelle Nutzer in einem definierten passwdfile enthalten ist. Das ist praktisch das selbe wie pam_listfile , jedoch kommt es mit den : -getrennten Feldern von passwd -Files klar.

auth required pam_localuser.so file=/my/passwdfile

pam_succeed_if.so - Die PAM-if-Anweisung

Mit diesem Modul können diverse Characteristika des sich authentifizierenden Benutzers geprüft werden. Das sieht ungefährt so aus:

auth [Anweisungen] pam_succeed_if.so [Variable] [Operator] [Wert] {[Variable2] [Operator2] [Wert2] {...}}

Parameter:

• [Variable] ist jeweils eine der Charakteristika des sich authentifizierenden Benutzers:
  • login , name oder user : Der Name des Benutzers
  • uid : Die numerische UID des Benutzers
  • gid : Die numerische GID des Benutzers
  • shell : Die Default-Shell des Benutzers
  • home , dir oder homedir : Das Homedirectory des Benutzers
• [Operator] Der Operator zum Vergleich der [Variable] mit dem [Wert] . Mögliche Operatoren sind:
  • < oder lt ; <= oder le ; > oder gt ; >= oder ge : Numerische Vergleiche
  • = oder eq ; = oder ne : Numerische oder Textvergleiche
  • =~ oder glob : Testen der Variable gegen einen Globberausdruck
  • !~ oder noglob : Testen der Variable gegen einen Globberausdruck - Erfolg, wenn es nicht matcht.
  • ingroup bzw. notingroup : Testen, Ob der Benutzer in der angegebenen Gruppe ist oder nicht.
• debug Viele Informationen ans Syslog schicken.
• quiet Keine Informationen über Erfolg oder Misserfolg des Plugins ans Syslog schicken.

pam_rootok.so

Dieses Plugin liefert success zurück, wenn der ursprüngliche Benutzer ( ruser ) root ist. Das ist z.B. für su sinnvoll, um die Authentifikation immer gelingen zu lassen, wenn root su benutzt.

pam_securetty.so

Mit diesem Modul kann der aktuelle Terminal mit der Liste "sicherer" Terminals in /etc/securetty verglichen werden. Ist der aktuelle tty nicht in der Liste, kann sich root nicht anmelden.

Hinweis:

• Gelegentlich findet man dieses Plugin so konfiguriert in einem PAM-Stack, wobei die Idee ist, dass sich root nicht über ungesicherte telnet -Verbindungen anmelden können soll. In Zeiten von ssh macht das aber keinen Sinn mehr - da ist die Anmeldung per ssh teilweise sicherer als die lokale (Stichwort: Public-Key-Authentication) - anhand des Terminals kann man das aber nicht feststellen, da ssh wie auch telnetd einfach Pseudo-Terminals ( /dev/pts/* ) nutzt.

pam_unix.so

Dieses Plugin authentifiziert gegen das Passwortfeld der Benutzerdatenbank ( passwd -Bereich des libc- Name Service Switch (NSS) ). Das heisst üblicherweise, dass /etc/passwd die Authentifikationsinformationen liefert, jedoch kann man das flexibel in /etc/nsswitch in der passwd: -Zeile konfigurieren. z.B. kann man so auch gegen ldap, nis oder gegen eine AFS-PTDB (siehe Dokumentation des InstantAFS^?-Projektes, Stichwort libnss-ptdb ).

pam_group.so

pam_group setzt nach bestimmten Bedingungen die Gruppenmitgliedschaften von Benutzern, die sich einloggen. Das Modul wird ohne Parameter als auth -Plugin eingesetzt und zieht die Regeln, nach denen es Gruppenmitgliedschaften vergibt, aus /etc/security/group.conf .

Die Regeln in /etc/security/group.conf bestehen jeweils aus 5 Feldern, die durch ; getrennt sind:

Gültige Kürzel für Tagesangaben im Zeit-Feld:

Beispiel:

*;*;*;Al0000-2359;audio,cdrom,cdrecording,video,floppy,plugdev,dip,netdev,dialout

Hinweise: *Das ist sehr nützlich, wenn man einfach jedem oder einzelnen Nutzern bestimmte Rechte geben will.

• Nicht existierende Gruppen werden stillschweigend ignoriert - erzeugen also keine mysteriösen Fehler.
• Das pam_group.so -Modul ist ungeeignet, um z.B. einen Rechner je nach Tageszeit zu sichern.

Zusätzliche Plugins

Debian-Paketierte Plugins

libpam-pwdfile : pam_pwdfile.so

Dieses Plufin ermöglicht die Authentifikation gegen ein alternatives passwd -File. Das geht so:

auth sufficient pwdfile /my/passwdfile

Redhat weiss alles besser

Redhat hat diverse Specials ins PAM der eigenen Distributionen eingebaut. Das umfasst vor allem eigene Plugins.

pam_console.so

Dieses Plugin sorgt (merkwürdigerweise als Session-Plugin, ich hab' keine Ahnung, wie das funktioniert...) dafür, dass entsprechend der Regeln in /etc/security/console.perms bestimmte Dateien (wobei man hier vor allem auf Device-Files zielt) an den sich einloggenden Benutzer abgetreten werden - der Owner wird also verändert. Daraus folgt, dass diese ganze Konstruktion nicht gerade Mehrbenutzertauglich ist. Ausserdem dürfte der Sicherheitsgewinn ähnlich gering wie bei pam_group.so sein - schliesslich kann man Rechte auf bereits geöffnete Dateien/Devices nicht aberkannt bekommen.

pam_stack.so

Führt einen anderen PAM-Stack als eine Art Unterprogramm aus.

Parameter:

• service=[service] Gibt den zu verarbeitenden PAM-Unterstack an.

Hinweise:

• PAM-Stack wird von vielen Praktikern gemieden, da es merkwürde Nebeneffekt bzw. komplettes No-Go produziert.
• Das @include -Statement kann praktisch dasselbe.

PAM unter Windows

http://pgina.xpasystems.com/^? ist ein Plugin-System für den Windows-Anmeldeprozess, das es - ähnlich wie PAM - ermöglicht, sich gegen verschiedene Authentifikationssysteme zu authentifizieren. Es gibt auch ein Plugin, das sich gegen einen Serverprozess auf einer Unix-Maschine authentifizieren kann, hinter dem dann ein PAM-Stack sitzt.

Links

• http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-4.html