Pam Konzepte

Modultype

• Die verschiedenen Funktionen, die PAM ausführt, sind in vier Gruppen einteilen.
• Jedes PAM-Modul ist mindestens einer dieser Gruppen zuzuordnen,
• Wobei viele Module in mehreren der Gruppen Funktionen erbringen.

account

• Überprüfen ob der Benutzer berechtigt ist den angefragten Dienst zu benutzen. ("Gibt es diesen Benutzer im System und darf er sich anmelden?")
• Steht der angestrebte Benutzerkonto für eine Authentisierung zur Verfügung?.
• Dies kann von Kriterien abhängen.
• Die Möglichkeiten sind vielfälltig

auth

• Benutzeridentifizierung und -authentifizierung. z.B. Passwortabfrage oder Smartcards. ("Zeig mir deinen Ausweis!")
• Die Identität des Benutzers wird hier geprüft.
• Dazu können sie zum Beispiel ein geheimes Kennwort erfragen
• Dies wird dann gegen eine Benutzerdatenbank gecheckt.
• LDAP, Datenbank, lokaler Account usw.
• Die Mechanismen wie gecheckt wird sind genauso vielfältig.
• Biometrisch, OTP, Password.
• Hier kann man aber auch über /etc/group User besonderen Gruppen zuweisen.

password

• Es kann hier unabhängig von dem dahinterliegenden Auth Dienst das Passwort geändert werden.
• Also egal ob das Passwort dann in einer LDAP oder SQL Datenbank oder sonst wo liegt.
• Des weiteren kann man die Passwortsicherheit hier sehr feingranuliert einstellen.

session

• Verwaltung und Konfiguration der Benutzer Sitzung. Limits, Berechtigungen ... während des Zugriffs.
• Die Module werden vor und nach der Authentifizierung gestartet um etwas zu protokolieren und dem Benutzer seine eigene Umgebung zuzuweisen.
• (z.B. Homeverzeichnis)

Modulsteuerung

requisite

• Modul muss mit Erfolg enden. Bei Fehler werden keine weiteren Module abgearbeitet. (notwendige Vorbedingung)

required

• Modul muss mit Erfolg enden. Bei Fehler werden weitere Module abgearbeitet. (notwendige Bedingung)

sufficient

• Wenn das Modul erfolgreich endet, reicht das für den Erfolg der Kette.
• Keine weiteren Module werden abgearbeitet. (hinreichende Bedingung)

optional

• Das Ergebnis dieses Moduls findet keine Beachtung. (Es sei denn es ist das einzige für einen Typ)

Alternativ zu den »traditionellen« Schlüsselwörtern

• Sie können auch eine weitaus differenziertere Methode verwenden.
• Diese gestattet, genau festzulegen, wie PAM mit den verschiedenen Rückgabewerten von Modulen umgehen soll.
• Dabei hat der Eintrag in der zweiten Spalte die Form

Traditionell	Modern
required	[success=ok new_authtok_reqd=ok ignore=ignore default=bad]
requisite	[success=ok new_authtok_reqd=ok ignore=ignore default=die]
sufficient	[success=done new_authtok_reqd=done default=ignore]
optional	[success=ok new_authtok_reqd=ok default=ignore]

[wert1 = aktion1 wert_2 = aktion_2 ...]

Werte

success

• Das Modul sagt das es ok ist.
• success=n means "skip the next n rules",

ignore

• Modul signalisiert, dass sein Rückgabewert ignoriert werden soll

abort

• Modul sagt Stopp jetzt

default

• alle Rückgabewerte, die nicht explizit in diesem [Satz] erwähnt werden', oft verwendet, um alle Fehler/Ausfälle abzufangen (weil es eine Menge davon gibt)

new_authtok_reqd

• Bei new_authok_reqd wird ein neues Passwort angefordert, wenn es leer oder veraltet ist.

errors/failures include

open_err, symbol_err, service_err, system_err, buf_err, auth_err, session_err, cred_err, conv_err, authtok_err, authtok_recover_err user_unknown, perm_denied, cred_insufficient, authinfo_unavail, new_authtok_reqd, authtok_lock_busy, authtok_disable_aging, authtok_expired, acct_expired, maxtries, cred_unavail, cred_expired, try_again, module_unknown, bad_item, conv_again, incomplete, no_module_data

actions

ignore

• Der Rückgabestatus des Moduls trägt nicht zum Rückgabecode des Stacks bei

bad

• uns selbst als gescheitert kennzeichnen (beendet nicht)

die

• bad, und terminate

ok

• der Rückkehrcode dieses Moduls sollte berücksichtigt werden (...wenn es keine Fehler gibt)

done

• ok, and termination

n

• (an integer ≥1) - ok, and skip the next n rules

reset

• clear stack module state