Benutzerdefinierte PAM-Module und Sicherheitsaspekte

Ich schreibe mein eigenes PAM-Modul, das Teil einer von mir entwickelten Anwendung sein wird, bin mir aber nicht sicher, wo ich es genau platzieren soll. Mein Modul führt im Grunde eine Authentifizierung auf Netzwerkebene durch (natürlich mit anderen Mojo), ähnlich wie LDAP.

In meinem /etc/pam.d/Verzeichnis befinden sich viele Konfigurationsdateien , und ich weiß, was die meisten Dienste tun (außer ein paar wie atd, polkit, ppp). Ich gehe davon aus, dass die Authentifizierung mit dem PAM-Stack ungefähr so ​​aussieht:

1. Führt einen Stapel basierend auf dem Dienstnamen aus (falls eine Konfigurationsdatei vorhanden ist)
2. Wenn Sie nicht authentifiziert sind, greifen Sie auf common- * zurück, wobei * der Modultyp ist (auth, account usw.).
3. Erfolg zurückgeben oder Anwendung nicht aufrufen (und natürlich alle anderen Daten)

Bin ich in dieser Annahme richtig? Verfügen alle Plattformen über Common-Auth, Common-Account, Common-Passwort und Common-Session?

Wenn ja, habe ich darüber nachgedacht, es als sufficientModul ganz oben auf common- * zu setzen, damit der reguläre PAM-Stack bei einem Ausfall nicht betroffen ist. Dies ist besonders vorteilhaft, da ich dies bei der Softwareinstallation programmgesteuert tun kann.

Vermisse ich potenzielle Sicherheitslücken?

Ich konnte keine sehr gute Dokumentation darüber finden, wo benutzerdefinierte PAM-Module integriert werden sollen, oder Sicherheitsprobleme im Zusammenhang mit der Platzierung von Modulen.

Wenn Sie Linux-PAM für ein Authentifizierungsverfahren aufrufen, wird immer nur ein Stapel ausgeführt.

Die Stapeldefinition wird an diesen Stellen nachgeschlagen. Der erste erfolgreiche Versuch bestimmt, welche Datei gelesen wird:

1. Die Datei wird /etc/pam.dnach der Anwendung "Dienstname" (z. B. sshdoder gdm) benannt

2. die Datei, /etc/pam.d/otherwenn keine dienstspezifische Datei vorhanden ist, oder

3. Die Datei, /etc/pam.confwenn das Verzeichnis /etc/pam.dnicht vorhanden ist.

Weitere Informationen finden Sie in der Dokumentation zur Funktion pam_start .

Die Common- * -Dateien sind eine Konvention, die von vielen Linux-Distributionen befolgt wird, jedoch nicht von der PAM-Software selbst vorgeschrieben wird. Sie werden normalerweise durch andere PAM-Dateien mithilfe von @include Anweisungen eingeschlossen. Zum Beispiel hat die /etc/pam.d/otherDatei auf Debian den folgenden Inhalt:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

Die gleichen @includeAussagen können auch durch dienstspezifische Datei verwendet werden, und -indeed- sie in der sind Standardkonfiguration auf Debian. Beachten Sie, dass dies eine Frage der Konfiguration ist: Ein Systemadministrator kann die Datei so ändern /etc/pam.d, dass sie überhaupt keine allgemeinen * Dateien enthält!

Deshalb: Wenn Ihr PAM-Modul für Ihre Anwendung spezifisch ist, erstellen Sie eine anwendungsspezifische Servicedatei und rufen Sie das Modul von dort aus auf. Fügen Sie weder der PAM-Datei anderer Dienste noch der Fallback-Datei automatisch ein Modul hinzu others, da dies andere auf dem System installierte Anwendungen beschädigen kann. Die Verwaltung des PAM-Software-Stacks ist eine Aufgabe des Systemadministrators, nicht der Anwendungsentwickler.