Introduction
Cet article fait suite à l'article "Authentification avec PAM sous Linux" paru en novembre 2025, qui présentait les principes de fonctionnement de PAM. Le présent article présente une synthèse des fonctions d'une cinquantaine de modules PAM. Son objectif n'est pas de remplacer leurs pages de manuels, mais de décrire de façon brève la fonction des modules, et, le cas échéant, d'apporter des informations ne figurant pas dans les pages de manuel.
Quelques rappels et compléments sur PAM seront effectués dans le paragraphe Généralités.
1. Généralités
1.1. Modules présentés
Les modules présentés dans cet article sont les suivants :
pam_access PAM module for logdaemon style login access control
pam_cap PAM module to set inheritable capabilities
pam_debug PAM module to debug the PAM stack
pam_deny The locking-out PAM module
pam_duo PAM module for Duo authentication
pam_echo PAM module for printing text messages
pam_env PAM module to set/unset environment variables
pam_exec PAM module which calls an external command
pam_faildelay Change the delay on failure per-application
pam_faillock Module counting authentication failures during a specified interval
pam_filter PAM filter module
pam_fprintd PAM module to authenticate against fprintd, the fingerprint daemon
pam_ftp PAM module for anonymous access module
pam_geoip GeoIP account management module for (Linux-)PAM
pam_getenv get environment variables from /etc/environment
pam_google_authenticator PAM module for Google two-factor authentication
pam_group PAM module for group access
pam_issue PAM module to add issue file to user prompt
pam_keyinit Kernel session keyring initialiser module
pam_lastlog PAM module to display date of last login and perform inactive account
lock out
pam_limits PAM module to limit resources
pam_listfile deny or allow services based on an arbitrary file
pam_localuser require users to be listed in /etc/passwd
pam_loginuid Record user's login uid to the process attribute
pam_mail Inform about available mail
pam_mkhomedir PAM module to create users home directory
pam_motd Display the motd file
pam_namespace PAM module for configuring namespace for a session
pam_newnet create a new network namespace at login
pam_nologin Prevent non-root users from login
pam_permit The promiscuous module
pam_pwhistory PAM module to remember last passwords
pam_pwquality PAM module to perform password quality checking
pam_rhosts The rhosts PAM module
pam_rootok Gain only root access
pam_script PAM module that can invoke scripts within the PAM stack
pam_securetty Limit root login to special devices
pam_sepermit PAM module to allow/deny login depending on SELinux enforcement state
pam_setquota PAM module to set or modify disk quotas on session start
pam_shells PAM module to check for valid login shell
pam_ssh_agent_auth PAM module for granting permissions based on SSH agent requests
pam_stress The stress-testing PAM module
pam_succeed_if test account characteristics
pam_systemd Register user sessions in the systemd login manager
pam_time PAM module for time control access
pam_timestamp Authenticate using cached successful authentication attempts
pam_tty_audit Enable or disable TTY auditing for specified users
pam_umask PAM module to set the file mode creation mask
pam_unix Module for traditional password authentication
pam_userdb PAM module to authenticate against a db database
pam_usernet join the user own network namespace at login
pam_usertype check if the authenticated user is a system or regular account
pam_warn PAM module which logs all PAM items if called
pam_wheel Only permit root access to members of group wheel
pam_xauth PAM module to forward xauth keys between users
1.2. Localisation des configurations applicatives
Les modules PAM sont utilisés dans les configurations applicatives localisées dans le fichier /etc/pam.conf ou, plus généralement, dans des fichiers du répertoire /etc/pam.d. Les modules sont, eux, situés dans le répertoire /lib/x86_64-linux-gnu/security (pour Debian).
1.3. Groupes de gestion des modules PAM
Les modules PAM peuvent être utilisés dans quatre modes de gestion : auth, account, password et session. Il est possible, en cas de doute, de trouver ceux qui sont effectivement gérés par un module pam_xxxx.so donné à l'aide de la commande :
# nm -D --defined-only /lib/x86_64-linux-gnu/security/pam_xxxx.so | grep '\<pam_'
Cette commande est valable sous Debian, et peut nécessiter d'être adaptée sur d'autres distributions.
1.4. Description de la syntaxe de la directive de contrôle
Dans l'article précédent (Authentification avec PAM sous Linux), nous avions écrit qu'il existait une syntaxe plus compliquée pour la spécification de la directive control. Elle est décrite dans la man page de pam.conf. Voici en quoi consiste cette syntaxe. Elle est de la forme :
[value1=action1 value2=action2 ...]
où valueN correspond au code retour de la fonction invoquée dans le module spécifié par la directive de configuration (la ligne du fichier pam.conf ou /etc/pam.d/app) dans laquelle il est référencé.
Cette valeur doit être l'un des mots-clés suivants :
success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete, ou default.
La valeur default correspond à "n'importe quelle autre valeur non explicitement mentionnée".
L'intégralité des codes retours de PAM est décrite dans le fichier /usr/include/security/_pam_types.h.
Quant aux actions (actionN), elles peuvent prendre les valeurs suivantes :
- ignore : dans le contexte d'une pile de modules, le code retour du module ne contribue pas au code retour renvoyé à l'application; comme l'indique le nom de l'action, il est ignoré,
- bad : cette action indique un échec global de la pile, mais les exécutions de la pile continuent pour des raisons de sécurité de façon à ne pas indiquer où l'échec a eu lieu,
- die : cette action a le même effet que l'action bad mais l'exécution de la pile est immédiatement interrompue,
- ok : cette action indique que le code retour du module doit contribuer au code retour de la pile, mais un statut d'erreur précédent sera prioritaire sur ce statut OK,
- done : cette action est identique à l'action ok, mais avec un retour immédiat à l'application,
- N (entier non signé) : saute les N prochaines directives de la pile,
- reset : efface les états antérieurs de la pile et continue avec le prochain module de la pile.
Il existe des équivalences entre certains mots-clés de contrôle (voir l'article précédent) et la syntaxe entre crochets [...] :
- 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]
1.5. Recommandations
Avant de mettre en place de nouvelles configurations PAM sur des serveurs, quelques recommandations de bon sens s'imposent :
- effectuez vos tests sur des machines hors production car de mauvaises configurations pourraient rendre impossible l'accès à certains services, les plus problématiques étant les services de connexion aux machines : login, sshd, etc.,
- n'oubliez pas l'extension .so derrière le nom de chaque module (par exemple pam_echo.so et non pam_echo),
- testez vos configurations avec la commande pamtester (voir pamtester(1)),
- consultez si nécessaire les logs système pour valider la chronologie des opérations,
- lors de la mise au point de vos configurations applicatives, n'oubliez pas que les fichiers /etc/pam.d/common-* contiennent des appels à d'autres modules PAM qui peuvent impacter le fonctionnement de votre application,
- lors des tests applicatifs, avant de soupçonner un problème de configuration ou un bug PAM, il faut vérifier que l'on teste bien la bonne configuration applicative, en particulier dans le cas des applications qui donnent accès à des services similaires comme, par exemple, login, sshd et lightdm.
1.6. Packages Debian contenant des modules PAM
Debian 12 fournit un grand nombre de packages contenant des modules PAM dont la liste peut être obtenue à l'aide de la commande suivante :
# apt-cache search '^libpam-' | sort
En voici le résultat mis en forme :
libpam-abl blocks hosts attempting a brute force attack
libpam-afs-session PAM module to set up a PAG and obtain AFS tokens
libpam-alreadyloggedin PAM module to skip password authentication for logged users
libpam-apparmor changehat AppArmor library as a PAM module
libpam-barada PAM module to provide two-factor authentication based on HOTP
libpam-biometric Insertable authentication module for PAM
libpam-cap POSIX 1003.1e capabilities (PAM module)
libpam-ccreds Pam module to cache authentication credentials
libpam-cgfs PAM module for managing cgroups for LXC
libpam-cgroup control and monitor control groups (PAM)
libpam-chroot Chroot Pluggable Authentication Module for PAM
libpam-doc Documentation of PAM
libpam-duo PAM module for Duo Security two-factor authentication
libpam-elogind elogind PAM module
libpam-encfs PAM module to automatically mount encfs filesystems on login
libpam-fprintd PAM module for fingerprint authentication through fprintd
libpam-freerdp2 PAM Module to auth against an RDP server using FreeRDPv2
libpam-freerdp2-dev PAM Module to auth against an RDP server using FreeRDPv2 (development
files)
libpam-fscrypt PAM module for Linux filesystem encryption
libpam-geoip PAM module checking access of source IPs with a GeoIP2 database
libpam-gnome-keyring PAM module to unlock the GNOME keyring upon login
libpam-google-authenticator Two-step verification
libpam-heimdal PAM module for Heimdal Kerberos
libpam-krb5 PAM module for MIT Kerberos
libpam-krb5-migrate-heimdal PAM module for migrating to Heimdal Kerberos
libpam-krb5-migrate-mit PAM module for migrating to MIT Kerberos
libpam-kwallet-common KWallet integration with PAM (common files)
libpam-kwallet5 KWallet (Kf5) integration with PAM
libpam-ldapd PAM module for using LDAP as an authentication service
libpam-malcontent PAM module to control the time a user is spending on the computer
libpam-mklocaluser Configure PAM to create a local user if it does not exist already
libpam-modules Pluggable Authentication Modules for PAM
libpam-modules-bin Pluggable Authentication Modules for PAM - helper binaries
libpam-mount PAM module that can mount volumes for a user session
libpam-mount-bin PAM module that can mount volumes for a user session - helper
libpam-mysql PAM module interfacing with MySQL databases
libpam-net create/join network namespaces at login
libpam-oath OATH Toolkit libpam_oath PAM module
libpam-ocaml OCaml bindings for the PAM library (runtime)
libpam-ocaml-dev OCaml bindings for the PAM library (development files)
libpam-otpw Use OTPW for PAM authentication
libpam-p11 PAM module for using PKCS#11 smart cards
libpam-passwdqc PAM module for password strength policy enforcement
libpam-pkcs11 Fully featured PAM module for using PKCS#11 smart cards
libpam-poldi PAM module allowing authentication using a OpenPGP smartcard
libpam-pwdfile PAM module allowing authentication via an /etc/passwd-like file
libpam-pwquality PAM module to check password strength
libpam-python Enables PAM modules to be written in Python
libpam-python-doc Documentation for the bindings provided by libpam-python
libpam-radius-auth PAM RADIUS authentication module
libpam-runtime Runtime support for the PAM library
libpam-script PAM module which allows executing a script
libpam-shield locks out remote attackers trying password guessing
libpam-shishi PAM module for Shishi Kerberos v5
libpam-slurm PAM module to authenticate using the Slurm resource manager
libpam-slurm-adopt PAM module to authenticate users running a Slurm job and track their
processes
libpam-snapper PAM module for Linux filesystem snapshot management tool
libpam-ssh-agent-auth PAM Authentication via forwarded ssh-agent
libpam-sss Pam module for the System Security Services Daemon
libpam-systemd system and service manager - PAM module
libpam-tmpdir automatic per-user temporary directories
libpam-u2f universal 2nd factor (U2F) PAM module
libpam-ufpidentity PAM library for UFP identity
libpam-winbind Windows domain authentication integration plugin
libpam-wrapper Tool to test PAM applications
libpam-x2go PAM Module to check credentials against X2Go servers
libpam-x2go-dev PAM Module to check credentials against X2Go servers (development files)
libpam-yubico two-factor password and YubiKey OTP PAM module
libpam-zfs PAM module for managing encryption keys for ZFS
libpam0g-dev Development files for PAM
Seul un sous-ensemble des modules contenus dans ces packages fera l'objet d'une description dans cet article afin de ne pas surcharger cet article avec des modules peu utilisés ou insuffisamment documentés.
1.7. Notes
Les types de modules qui sont donnés ci-après correspondent aux modes de gestion disponibles dans PAM et gérés par les modules. Ils ont été décrits au paragraphe 1.3 : Groupes de gestion des modules PAM.
Tous les modules n'ont pas pu être testés de façon exhaustive par nos soins.
Passons maintenant en revue quelques-uns des modules PAM existants.
2. Examen de quelques modules PAM
2.1. Module pam_access
Le module pam_access contrôle l'accès en se basant sur les noms des utilisateurs (username), les noms des hôtes (hostname), les adresses IP des machines (IP address) ou des réseaux (network number), le contenu de la variable DISPLAY pour les terminaux X, le nom du service PAM utilisé (figurant dans /etc/pam.d : par exemple login, sshd, su, sudo, etc.) ou, dans le cas de connexions n'utilisant pas le réseau, des noms de terminaux (TTY).
Le fichier de configuration de ce module est /etc/security/access.conf. Sa syntaxe est fortement inspirée de celle des fichiers /etc/hosts.allow et /etc/hosts.deny du démon inetd (appelé logdaemon).
Types de modules : auth, account, password, session.
2.2. Module pam_cap
Le module pam_cap permet d'accorder des capacités supplémentaires (capabilities) à des utilisateurs spécifiés, mais pas d'en supprimer.
Le fichier de configuration de ce module est /etc/security/capability.conf .
Types de modules : auth.
2.3. Module pam_debug
Le module pam_debug est une aide à la mise au point ou débogage d'une pile PAM. Il retourne ce que ses arguments lui disent de retourner, cela permet de valider facilement le comportement de la pile PAM applicative sans nécessiter de créer les conditions d'une utilisation réelle. Il ne sert pas à afficher des messages destinés à tracer les opérations effectuées, mais uniquement à simuler des opérations sans avoir à les effectuer réellement.
Types de modules : auth, account, password, session.
2.4. Module pam_deny
Le module pam_deny a pour seul but de retourner un échec à l'application appelante. Le code retour est différent selon le type de gestion, mais indique toujours un échec :
- PAM_AUTH_ERR pour les types auth et account,
- PAM_CRED_ERR pour la fonction setcred,
- PAM_AUTHTOK_ERR pour le type password,
- PAM_SESSION_ERR pour le type service.
Ce module doit être utilisé pour verrouiller une pile PAM dans le but d'invalider toutes les demandes non explicitement autorisées.
Types de modules : auth, account, password, session.
2.5. Module pam_duo
Le module pam_duo fournit un moyen pour une deuxième authentification, après une première authentification réussie, en utilisant le service Duo de Duo Security (intégré au système Cisco en 2018).
Le fichier de configuration est /etc/duo/pam_duo.conf .
Types de modules : auth, account, password, session.
2.6. Module pam_echo
Le module pam_echo sert à afficher des messages à l'utilisateur. Il peut afficher le contenu de fichiers texte ou des valeurs particulières grâce à des mots-clés utilisant une syntaxe inspirée de printf() : %h, %H, %s, %t, ...
Sa syntaxe est imparfaitement décrite, mais il est possible de lui passer des chaînes de caractères avec ou sans mots-clés, ou une option indiquant le fichier à afficher, celui-ci pouvant contenir des mots-clés qui seront remplacés par leur valeur lors de l'affichage.
Types de modules : auth, account, password, session.
2.7. Module pam_env
Le module pam_env sert à initialiser des variables d'environnement, mais il faut faire très attention lors de sa configuration car elle comporte de nombreux pièges, du moins pour la version étudiée sur Debian bookworm (version 12).
Trois fichiers de configuration peuvent être utilisés par ce module en fonction d'arguments en ligne de commande (readenv=1, user_readenv=1) :
(1) /etc/security/pam_env.conf
(2) /etc/environment (readenv=1)
(3) $HOME/.pam_environment (user_readenv=1)
Parmi les pièges détectés en étudiant ce module, il apparaît que les analyseurs syntaxiques de (2) et (3), qui ont pourtant la même grammaire, sont différents : le premier tolère les quotes autour des valeurs des variables, mais pas le deuxième, pour lequel les quotes feront partie intégrante de la valeur de la chaîne. D'autre part, dans (2), des espaces placés après la valeur de la variable dans une expression du type :
TOTO="toto"
auront pour effet de donner à la variable TOTO la valeur [toto" ] (sans les crochets qui servent ici à matérialiser les espaces), c'est-à-dire que la première quote, simple ou double, sera bien supprimée, mais pas la deuxième, ni les espaces qui la suivent.
Dans (3), c'est encore pire : le moindre espace, dans la chaîne ou après la chaîne, a pour effet d'invalider la ligne, comme si elle était commentée.
D'autre part, dans (1), les quotes, si elles sont présentes, doivent être doubles. Si elles sont simples, elles feront partie intégrante de la chaîne.
En ce qui concerne l'affectation d'une valeur à une variable dans le cas où les trois fichiers de configuration sont utilisés (readenv=1 user_readenv=1), la priorité est la suivante : le fichier (3) est le plus prioritaire, puis (1), puis (2), mais attention : si une variable est définie dans (1) en fonction d'une variable également définie dans (1), et aussi définie dans (3), sa valeur utilisera la valeur de la variable définie dans (1) et non la valeur définie dans (3). L'exemple suivant sera plus parlant :
Dans (1), nous avons :
TOTO DEFAULT="toto_pam_env_conf" OVERRIDE=${TITI}
TITI DEFAULT="titi_pam_env_conf"
et dans (3), nous avons :
TITI=titi_home_pam_environment
Dans ce cas, la valeur résultante de TOTO sera titi_pam_env_conf, et non titi_home_pam_environment ainsi que les priorités précédentes auraient pu le laisser supposer.
En synthèse, le conseil que l'on peut donner est d'être particulièrement vigilant lors de l'utilisation de ce module, et de tester toutes les configurations que l'on doit utiliser avant une mise en production !
Types de modules : auth, account, password, session.
2.8. Module pam_exec
Le module pam_exec permet l'exécution d'une commande dont l'environnement est identique à l'environnement courant du module, auquel sont ajoutées les variables PAM_RHOST, PAM_RUSER, PAM_SERVICE, PAM_TTY, PAM_USER, et la variable PAM_TYPE qui contient le type de module : account, auth, password, open_session ou close_session.
Types de modules : auth, account, password, session.
2.9. Module pam_faildelay
Le module pam_faildelay sert à définir un délai configurable en cas d'échec d'authentification, afin de ralentir les attaques par force brute.
Le fichier de configuration utilisé est /etc/login.defs .
Types de modules : auth.
2.10. Module pam_faillock
Le module pam_faillock sert à réduire les attaques par force brute en verrouillant temporairement ou définitivement les comptes utilisateurs après des tentatives de connexions infructueuses. Il maintient une liste des échecs d'authentification par utilisateur durant un intervalle spécifié et verrouille le compte en cas de dépassement de seuil.
Les nombreux paramètres disponibles permettent de configurer le délai, le nombre d'échecs tolérés, la durée de verrouillage, le fichier de configuration, le fichier d'enregistrement, etc.
Le fichier de configuration est /etc/security/faillock.conf .
Types de modules : auth, account.
2.11. Module pam_filter
Le module pam_filter permet d'insérer un filtre entre une application et l'utilisateur pour traiter le flux d'entrée/sortie (texte), par exemple pour convertir des pages de codes (codepage). Il requiert l'installation de filtre(s) spécifiques pour pouvoir fonctionner. Son usage est uniquement adapté aux applications basées sur les TTY.
Le filtre de démonstration est un programme qui change la casse des caractères (upperLOWER.c). Il peut servir de base pour développer des programmes plus utiles.
Types de modules : auth, account, password, session.
2.12. Module pam_fprintd
Le module pam_fprintd permet de comparer les empreintes digitales d'un utilisateur avec celles qui ont été enregistrées par le démon fprintd.
Types de modules : auth, password.
2.13. Module pam_ftp
Le module pam_ftp permet un mode d'accès FTP anonyme.
Il est écrit dans la page de manuel que ce module n'est pas sûr et aisément falsifiable : à déconseiller dans un contexte où la sécurité est importante.
Types de modules : auth.
2.14. Module pam_geoip
Le module pam_geoip permet d’autoriser, de refuser ou d’ignorer une connexion en fonction de la localisation géographique de l’adresse IP du client. La localisation utilise des bases de données de type GeoIP2, disponibles de façons gratuites (GeoLite2 Country ou City de MaxMind) ou payantes (GeoIP Contry ou City de MaxMind, ou des bases d'autres sociétés comme Infobel PRO, HG Insights, etc.).
Il faut cependant garder à l'esprit que la localisation par adresse IP est très imprécise.
Les fichiers de configuration sont les suivants :
- /etc/security/geoip.conf .
- /etc/security/geoip.SERVICE.conf ,
- /etc/GeoIP.conf .
Types de modules : account.
2.15. Module pam_getenv
Contrairement à ce que peut laisser penser la présence de la page de manuel pam_getenv(8), il n'existe pas de module pam_getenv.so . Cette page de manuel décrit un utilitaire Perl dont le pathname est /usr/sbin/pam_getenv et qui est disponible dans le package libpam-runtime.
L'utilitaire pam_getenv affiche la valeur de la variable spécifiée en argument d'après les spécifications la concernant dans le fichier /etc/environment.
2.16. Module pam_google_authenticator
Le module pam_google_authenticator permet un renforcement de la sécurité grâce à une authentification à deux facteurs (2FA : 2 Factor Authentication) utilisant TOTP (Time-based One-Time Password) qui est basée sur le temps, ou HOTP (HMAC-based One-Time Password, HMAC : Hashed Message Authentication Code) qui est basée sur un compteur. Le principe de TOTP est décrit dans la RFC 6238, et celui de HTOP dans la RFC 4226.
Avant de pouvoir se connecter, l'utilisateur doit fournir son identifiant et son mot de passe, ainsi qu'un code généré par un équipement personnel tel qu'un smartphone. Avant l'époque des smartphones, cette double authentification était réalisée à l'aide des clés SecurID (RSA SecurID).
Types de modules : auth.
2.17. Module pam_group
Le module pam_group permet d'ajouter des groupes à la liste des groupes de l'utilisateur tels que définis dans /etc/group, pendant la durée de la session. Pour des raisons de sécurité, les utilisateurs de ce module devraient être confinés dans des environnements ne leur donnant accès qu'à des filesystems montés avec l'option nosuid, faute de quoi l'attribution temporaire des droits d'un groupe pourrait être transformée par l'utilisateur en attribution définitive grâce à un petit programme pourvu d'un bit SGID.
Attention donc à l'utilisation de ce module en environnement sécurisé.
Le fichier de configuration est /etc/security/group.conf.
Types de modules : auth.
2.18. Module pam_issue
Le module pam_issue servait auparavant à initialiser la variable PAM_USER_PROMPT dans le but d'afficher un message destiné à l'utilisateur devant le prompt login: , mais il n'est plus vraiment utile actuellement car l'utilisation du programme /sbin/agetty rend le mécanisme inopérant. En effet, pour que celui-ci fonctionne (et que le prompt contenu dans PAM_USER_PROMPT soit affiché), il faut que la commande login demande le nom de l'utilisateur, mais comme celui-ci a déjà été demandé par la commande /sbin/agetty et lui est passé via la variable PAM_USER, la commande login n'a pas besoin de demander l'identifiant, et donc pas besoin d'afficher le prompt.
Une façon d'afficher le contenu du fichier passé à pam_issue.so , afin de vérifier le mécanisme mis en jeu, est d'appeler directement la commande login depuis un shell sous root : appelée de cette façon, la commande login ne connaît pas le nom de l'utilisateur, elle passe donc bien par la demande du nom d'utilisateur et affiche le prompt.
On peut utiliser la configuration suivante pour effectuer le test :
auth optional pam_issue.so issue=/etc/issue.custom1
(cette ligne doit être placée très haut dans le fichier /etc/pam.d/login, de préférence en tête).
Le contenu du fichier /etc/issue.custom1 est, par exemple le suivant :
custom (1) \d \l \m \n \t
La commande login, appelée depuis un shell root, affichera alors un message qui ressemble au suivant :
custom (1) Tue Jan 6 2026 pts/3 x86_64 debian12-tests 18:53:40 debian12-tests login:
Par contre, lors d'une connexion sur un TTY (de tty01 à tty12, par exemple), le message contenu dans le fichier dont le nom est passé en argument à pam_issue.so ne sera pas affiché.
En synthèse, on peut dire que dans des conditions classiques d'utilisation, ce module n'a plus grande utilité.
2.19. Module pam_keyinit
Le module pam_keyinit garantit que le processus appelant utilise un trousseau de clés de session (session keyring) différent du trousseau utilisateur par défaut lors de l'établissement d'une session utilisateur. Il sert à cloisonner les secrets entre les différentes sessions utilisateurs.
Types de modules : auth (pam_setcred(3) uniquement), session.
2.20. Module pam_lastlog
Le module pam_lastlog permet l'affichage des informations relatives à la dernière connexion de l'utilisateur (date, heure, adresse IP, TTY) ainsi que le nombre de tentatives de connexions infructueuses. Il peut aussi verrouiller le compte d'un utilisateur après un certain nombre de jours sans connexions. Il dispose également de l'option unlimited permettant de contourner la limite des UID des utilisateurs et destinée à brider la taille du fichier /var/log/lastlog (ce fichier, implémenté sous forme de sparse file, peut atteindre la taille de 1,2 To avec des UID de l'ordre de 232, et peut engendrer des problèmes avec les commandes ne sachant pas manipuler correctement les sparse files).
Ce module utilise le fichier /etc/login.defs .
Types de modules : auth, account, session.
2.21. Module pam_limits
Le module pam_limits sert à limiter les ressources disponibles (nproc, CPU, RAM, files, locks, priority, etc.) pour l'utilisateur après la phase d'authentification. Par défaut, les limites sont définies dans les fichiers /etc/security/limits.conf et /etc/security/limits.d/*.conf .
Remarque : les administrateurs système ont intérêt à indiquer clairement et de façon visible les limites qu'ils fixent s'ils veulent éviter les questions des utilisateurs, comme la limitation du nombre de connexions simultanées (maxlogins) pour laquelle la raison du refus de connexion n'est pas indiquée à l'utilisateur. L'information à connaître, relativement à cette limite, est qu'elle s'applique au login et pas au nombre de shells ouverts, donc il est possible d'ouvrir plusieurs fenêtres de terminal après une unique ouverture de session X.11, par exemple avec terminator, screen ou tmux.
Types de modules : session.
2.22. Module pam_listfile
Le module pam_listfile sert à autoriser ou interdire l'accès à un service, selon certains critères (tty, user, rhost, ruser, group, shell), conformément à un fichier arbitraire de descriptions. Il est par exemple possible grâce à lui d'autoriser la connexion au système à une liste d'utilisateurs spécifiée, ou au contraire d'en interdire l'accès à certains, ou encore d'interdire l'accès si le shell de connexion ne fait pas partie d'une liste de shells autorisés. Pour une restriction des connexions basée uniquement sur la validité du shell (dans /etc/shells), utilisez plutôt le module pam_shells, décrit plus bas, dont la configuration est plus simple.
Types de modules : auth, account, password, session.
2.23. Module pam_localuser
Le module pam_localuser permet d'interdire l'accès aux utilisateurs non listés dans le fichier /etc/passwd (ou dans un autre fichier spécifié), ou encore d'interdire un changement de mot de passe à un utilisateur non local.
Types de modules : auth, account, password, session.
2.24. Module pam_loginuid
Le module pam_loginuid est responsable de l'initialisation de l'identifiant loginuid (dans /proc/self/loginuid) qui permet la fiabilité de la traçabilité via l'audit système (auditd : voir Auditing sous Linux) d'un utilisateur réel malgré ses éventuels changements d'identité. Si cet identifiant a été rendu non-modifiable, par exemple par la commande :
# auditctl --loginuid-immutable
alors même l'utilisateur root ne peut plus le modifier :
# auditctl -s | grep loginuid loginuid_immutable 1 locked
# echo -n 123456 > /proc/self/loginuid -bash: echo: write error: Operation not permitted
Ce module est généralement présent dans les configurations des applications utilisées dans la connexion des utilisateurs, comme par exemple login, sshd et lightdm.
Types de modules : account, session.
2.25. Module pam_mail
Le module pam_mail examine la boîte email locale de l'utilisateur et lui affiche, le cas échéant, le message : you have new mail.
Types de modules : auth, session.
2.26. Module pam_mkhomedir
Le module pam_mkhomedir automatise la création du répertoire d'accueil d'un utilisateur ($HOME) si celui-ci n'existe pas quand la session démarre. Il est particulièrement utile car il décharge l'administrateur de la tâche de création des home directories des utilisateurs, en particulier dans le contexte de bases d'utilisateurs centralisées (LDAP, NIS, etc.).
Les fichiers de profile proviennent généralement du répertoire /etc/skel.
Ce module utilise le fichier /etc/login.defs .
Types de modules : session.
2.27. Module pam_motd
Le module pam_motd sert à afficher des messages à l'utilisateur après une connexion réussie au système. Plusieurs fichiers peuvent être affichés selon un ordre de priorité pré-établi :
- /etc/motd
- /run/motd
- /usr/lib/motd
Le module gère également des répertoires contenant potentiellement des fichiers texte qu'il concaténera afin de les afficher sur le terminal associé à la connexion de l'utilisateur. Ces répertoires, par ordre de priorité de traitement, sont les suivants :
- /etc/motd.d
- /run/motd.d
- /usr/lib/motd.d
Les fichiers contenus dans ces répertoires sont traités par ordre alphabétique (avec LANG=C) et concaténés, sous réserve d'être lisibles par l'utilisateur connecté.
Le répertoire /etc/update-motd.d peut contenir des scripts dont le résultat d'exécution sera également affiché sur le terminal de l'utilisateur avant le contenu du fichier /etc/motd. Bien évidemment, tout ceci est configurable avec un petit jeu de paramètres.
Types de modules : session.
2.28. Module pam_namespace
Le module pam_namespace permet de créer, pour une session, un espace privé de noms de montages avec des répertoires poly-instanciés, dans le but d'isoler les répertoires accessibles aux utilisateurs les uns des autres. Utilisé, par exemple, pour /tmp ou /home, il garantit qu'un utilisateur ne pourra pas voir les fichiers temporaires d'un autre utilisateur, ou accéder au répertoire d'accueil d'un autre utilisateur.
Les mécanismes mis en jeu par ce module viennent en complément de ceux fournis par SELinux dans le cadre de la mise en place d'une sécurité multi-niveaux (MLS). Il peut participer au renforcement du cloisonnement dans un contexte de gestion de niveaux de classification multiples tels que, par exemple : Non classifié / Diffusion Restreinte / Confidentiel / Secret / Très Secret.
Types de modules : session.
2.29. Module pam_newnet
Le module pam_newnet est un module utilisé pour isoler les sessions utilisateurs dans des espaces de noms de réseau (network namespaces) privés au moment de la connexion. Il permet d'isoler le trafic réseau de chaque utilisateur dans son propre namespace réseau, et évite ainsi les interférences avec les connexions réseau des autres utilisateurs et l'accès à des interfaces réseau non autorisées.
Types de modules : session.
Ce module provient du projet VirtualSquare de l'Université de Bologne.
2.30. Module pam_nologin
Le module pam_nologin sert à interdire la connexion au système aux utilisateurs différents de root. Cette interdiction prend effet lorsque le fichier /etc/nologin existe. Quand il existe, seuls les utilisateurs ayant l'UID 0 (généralement root uniquement) sont autorisés à se connecter. Les autres utilisateurs se voient refuser l'accès, et le contenu du fichier /etc/nologin est affiché à l'écran.
C'est une méthode rapide pour interdire l'accès aux utilisateurs car il suffit de créer le fichier /etc/nologin pour activer le mécanisme d'interdiction : pas de commande spécifique à lancer ni de configuration à mettre en place, le module pam_nologin.so est généralement inclus dans les configurations PAM de lightdm, login et sshd. C'est la méthode à employer pour interdire l'accès lors des phases de maintenance.
Types de modules : auth, account.
2.31. Module pam_permit
Le module pam_permit autorise systématiquement l'accès, et ne fait que cela.
Il faut faire attention à ne pas créer de faille de sécurité en l'utilisant (en validant involontairement un accès pour lequel l'autorisation aurait dû par défaut être refusée)..
Types de modules : auth, account, password, session.
2.32. Module pam_pwhistory
Le module pam_pwhistory mémorise les derniers mots de passe de l'utilisateur afin d'empêcher une réutilisation trop fréquente des mêmes mots de passe.
Types de modules : password.
2.33. Module pam_pwquality
Le module pam_pwquality sert à contrôler la robustesse d'un mot de passe, en se basant sur des règles définies dans le fichier /etc/security/pwquality.conf et sur des options passées sur la ligne de commande. Les contrôles portent sur les classes de caractères utilisées, la similarité avec le login name, la comparaison avec des mots du dictionnaire, la simplicité ou la prédictibilité de séquences.
Le fichier de configuration est /etc/security/pwquality.conf .
Types de modules : password.
2.34. Module pam_rhosts
Le module pam_rhosts est un module déprécié qui servait à l'authentification sans mot de passe des utilisateurs. Son principe était basé sur la confiance envers les hôtes et les utilisateurs. Il utilisait les fichiers /etc/hosts.equiv et ~/.rhosts.
De nos jours, son utilisation est fortement déconseillée.
Types de modules : auth.
2.35. Module pam_rootok
Le module pam_rootok vérifie que l'identité de l'utilisateur (UID) est 0. Les programmes suid appartenant à root ne font pas toujours la modification de la valeur de l'UID et conservent souvent l'UID originale de l'utilisateur. pam_rootok sert à vérifier que l'identité de l'utilisateur est bien root (UID = 0).
Types de modules : auth, account, password.
2.36. Module pam_script
Attention à la syntaxe de la page de manuel : pam-script est écrit avec un tiret et non un underscore. Le nom du module dans /lib/x86_64-linux-gnu/security est bien pam_script.so, mais le nom de sa page de manuel est orthographié PAM-SCRIPT(7), avec un tiret, donc on doit accéder à sa page de manuel avec la commande :
$ man pam-script
Le module pam_script (disponible dans le package libpam-script) permet d'exécuter des scripts lors des différentes phases de l'authentification. Les noms des scripts sont non-modifiables, en voici la liste :
- pam_script_auth
- pam_script_acct
- pam_script_passwd
- pam_script_ses_open
- pam_script_ses_close
Ils sont, par défaut, recherchés dans le répertoire /usr/share/libpam-script, mais il est possible de spécifier un nom de répertoire alternatif avec l'argument dir= .
Lors de la création des scripts destinés à pam_script, il faut utiliser le pathname complet des commandes externes au shell (non built-in) sous peine de risquer d'obtenir des erreurs à l'exécution.
Il faut aussi faire attention à la valeur du code retourné (exit code) par le script car une valeur non-nulle est considérée comme une erreur, et pourra entraîner un refus de connexion dans une phase auth, selon le mot-clé de contrôle utilisé.
L'appel à pam_script.so peut être effectué directement dans la configuration applicative (/etc/pam.d/app), mais certains fichiers /etc/pam.d/common-* contiennent également des appels à ce module. Si l'on doit ajoutez des scripts dans /usr/share/libpam-script, il ne faut pas oublier que certains d'entre-eux pourront être appelés via les fichiers common-* bien que l'on ait supprimé tout appel à pam_script.so dans la configuration applicative.
Types de modules : auth, account, password, session.
2.37. Module pam_securetty
Le module pam_securetty permet de restreindre la connexion en tant que root à certains terminaux répertoriés dans le fichier /etc/securetty. Il n'a pas d'effet sur les utilisateurs différents de root.
Le fichier de configuration utilisé est /etc/securetty.
Types de modules : auth, account.
2.38. Module pam_sepermit
Le module pam_sepermit sert à autoriser ou interdire l'accès au système à certains utilisateurs spécifiés selon les états de SELinux (disabled, permissive, enabled).
Un utilisateur dont le login name est listé dans le fichier de configuration ne sera autorisé à se connecter que si SELinux est en mode enforcing. S'il est dans un autre mode, l'accès lui sera refusé.
Le fichier de configuration utilisé est /etc/security/sepermit.conf.
Types de modules : auth, account.
2.39. Module pam_setquota
Le module pam_setquota sert à initialiser ou modifier les quotas de place disque pour un utilisateur lors de l'ouverture de session.
Ce module utilise le fichier /etc/login.defs .
Types de modules : session.
2.40. Module pam_shells
Le module pam_shells sert à interdire l'accès à un utilisateur si son shell de connexion (dans /etc/passwd ou dans LDAP) ne figure pas dans la liste des shells autorisés (/etc/shells).
Types de modules : auth, account.
2.41. Module pam_ssh_agent_auth
Le module pam_ssh_agent_auth est un module d'authentification qui utilise l'agent SSH (ssh-agent) pour valider l'identité d'un utilisateur via une clé privée chargée dans l'agent, sans demander de mot de passe.
Il permet, par exemple, d'utiliser la commande sudo sans mot de passe.
Types de modules : auth.
2.42. Module pam_stress
Le module pam_stress sert à tester la robustesse d'une configuration applicative en simulant diverses réponses destinées à l'application utilisatrice : une erreur sur la fonction 1 ou la fonction 2 du supposé module vis-vis (respectivement pam_sm_authenticate et pam_sm_setcred pour le mode auth, pam_sm_open_session et pam_sm_close_session pour le mode session, etc), une expiration de mot de passe, etc.
Il ne doit être utilisé que sur des machines de tests car le mode debug peut laisser des informations sensibles dans les fichiers de logs.
Types de modules : auth, account, password, session.
2.43. Module pam_succeed_if
Le module pam_succeed_if sert à effectuer un contrôle de flux sur une pile PAM dans le sens où il est capable d'évaluer une condition spécifiée et de renvoyer un code d'erreur (PAM_SUCCESS ou PAM_AUTH_ERR) permettant d'influer sur la suite de l'exécution des modules de la pile.
Sa syntaxe permet de tester les informations suivantes :
user, uid, gid, shell, home, ruser, rhost, tty et service.
Types de modules : auth, account, password, session.
2.44. Module pam_systemd
Le module pam_systemd assure l'enregistrement des sessions utilisateur auprès du gestionnaire de système et de services systemd. Il permet l'intégration des processus de connexion avec le mécanisme de suivi de systemd-logind.
Types de modules : session.
2.45. Module pam_time
Le module pam_time sert à restreindre l'accès aux utilisateurs et applications en fonction de l'horaire, mais aussi de leur nom (login name) et de la liaison TTY utilisée.
Les règles par défaut de restriction d'accès sont localisées dans le fichier /etc/security/time.conf.
Si PAM a été compilé avec le support de l'audit, le module enregistrera dans les logs les restrictions d'accès qu'il effectue.
Types de modules : account.
2.46. Module pam_timestamp
Le module pam_timestamp met en cache, pendant une durée limitée, un indicateur d'authentification réussie afin de ne pas redemander le mot de passe à chaque demande de connexion au service. Le principe est similaire au mécanisme mis en oeuvre dans la commande sudo avec la variable timestamp_timeout de /etc/sudoers.
Sur Debian, les indicateurs de connexions réussies sont stockés dans le répertoire /var/run/pam_timestamp/<user> .
Par exemple :
- pour l'utilisateur toto sur le terminal /dev/pts/4 ayant lancé la commande su titi, le fichier sera /var/run/pam_timestamp/toto/4:titi
- pour l'utilisateur toto sur le terminal tty2 ayant lancé la commande su - , le fichier sera /var/run/pam_timestamp/toto:tty2:root .
Les répertoires et fichiers cités ci-dessus appartiennent à root et, bien évidemment, ne sont pas modifiables par un utilisateur non privilégié. Ils contiennent d'autre part une information chiffrée qui limite les risques de contournement de la sécurité. Par contre, l'indicateur reste valide après une déconnexion / reconnexion, ce qui peut présenter une faille de sécurité. Un effacement de l'indicateur sur fermeture de session (avec pam_exec) sera donc le bienvenu dans le cas de l'utilisation de ce module.
Ce module utilise le fichier /etc/login.defs .
Types de modules : auth, session.
2.47. Module pam_tty_audit
Le module pam_tty_audit sert à capturer les frappes au clavier effectuées sur un TTY. Cette capture peut être restreinte à un utilisateur ou un groupe d'utilisateurs. Le résultat de la capture ne peut pas être visualisé en temps réel car plusieurs conditions doivent être remplies pour que les frappes soient envoyées dans les logs d'audit : fermeture de la session TTY ou remplissage du buffer associé au TTY.
Cette capture ne sert donc généralement qu'à une analyse forensics à postériori.
Types de modules : session.
2.48. Module pam_umask
Le module pam_umask gère l'initialisation du mode de création de fichiers (umask). Pour déterminer la valeur du masque à utiliser, il recherche, avec une priorité décroissante, les informations suivantes :
- la chaîne umask= dans le champ GECOS de l'utilisateur dans /etc/passwd,
- l'argument umask= sur sa ligne de commande,
- la valeur du paramètre UMASK dans le fichier /etc/login.defs,
- la valeur spécifiée par la chaîne umask= dans le fichier /etc/default/login.
En plus de la chaîne umask= , ce module reconnaît également la chaîne pri= pour la valeur de la priorité nice du processus, et la chaîne ulimit= pour la valeur de la taille maximale des fichiers que l'utilisateur est autorisé à créer.
Types de modules : session.
2.49. Module pam_unix
Le module pam_unix gère l'authentification classique Unix par mot de passe en utilisant le fichier /etc/passwd et le fichier /etc/shadow si ce dernier est présent (ce qui est généralement le cas). Il gère aussi (toujours dans le cas où le fichier /etc/shadow est présent) les paramètres relatifs au mot de passe : expire, last_change, max_change, min_change, warn_change.
- Le composant auth gère l'authentification de l'utilisateur.
- Le composant account gère l'établissement du status et du mot de passe de l'utilisateur en fonction des paramètres du fichier /etc/shadow.
- Le composant password gère les mises à jour du mot de passe de l'utilisateur, en utilisant la méthode de chiffrement définie par la variable ENCRYPT_METHOD du fichier /etc/login.defs.
- Le composant session enregistre dans les logs les connexions et déconnexions des utilisateurs.
Types de modules : auth, account, password, session.
2.50. Module pam_userdb
Le module pam_userdb permet une authentification à partir d'une base de données de type Berkeley DB. Il est généralement utilisé pour authentifier des utilisateurs virtuels, c'est-à-dire des utilisateurs non connus du système par /etc/passwd.
Types de modules : auth, account.
2.51. Module pam_usernet
Le module pam_usernet (de VirtualSquare Labs) assigne un namespace réseau dédié à chaque utilisateur du groupe usernet lors du login (utiliser ip netns list pour lister les namespaces réseau).
Types de modules : session.
2.52. Module pam_usertype
Le module pam_usertype sert à déterminer si un utilisateur est un utilisateur système ou un utilisateur standard. Il utilise les valeurs de SYS_UID_MIN et SYS_UID_MAX définies dans /etc/login.defs pour décider si l'authentification doit réussir ou échouer.
Le fichier utilisé par ce module est /etc/login.defs .
Types de modules : auth, account, password, session.
2.53. Module pam_warn
Le module pam_warn enregistre les informations service, terminal, user, remote user et remote host via la fonction syslog(). Ces informations sont récupérées à partir des items PAM standard. Ce processus n'affecte pas le processus d'authentification.
Rappel sur les items PAM
Les items PAM sont des paires clé-valeur accessibles via le handle pamh des modules PAM, et manipulables à l'aide des fonctions pam_set_item() et pam_get_item(). Leur valeur est définie dans le fichier /usr/include/security/_pam_types.h. A titre d'exemple, en voici quelques-uns :
#define PAM_SERVICE 1 /* The service name */ #define PAM_USER 2 /* The user name */ #define PAM_TTY 3 /* The tty name */ #define PAM_RHOST 4 /* The remote host name */ #define PAM_CONV 5 /* The pam_conv structure */ #define PAM_AUTHTOK 6 /* The authentication token (password) */ #define PAM_OLDAUTHTOK 7 /* The old authentication token */ #define PAM_RUSER 8 /* The remote user name */ #define PAM_USER_PROMPT 9 /* the prompt for getting a username */ #define PAM_FAIL_DELAY 10 /* app supplied function to override failure #define PAM_XDISPLAY 11 /* X display name */
Types de modules : auth, account, password, session.
2.54. Module pam_wheel
Le module pam_wheel sert à restreindre l'accès aux utilisateurs du groupe wheel, ou du groupe de GID 0 si le groupe wheel n'existe pas sur le système.
Types de modules : auth, account.
2.55. Module pam_xauth
Le module pam_xauth permet de faire suivre les fichiers xauth (appelés aussi "cookies") d'un utilisateur à un autre. Ce qui permet par exemple de continuer à utiliser un serveur X accessible par une variables DISPLAY lorsqu'on change d'identité en utilisant la commande su, sans avoir besoin d'utiliser la commande xauth ni les fichiers ~/.Xauthority. Attention toutefois, le cookie peut ne pas être transmis lorsque l'utilisateur exécutant la commande su est root : la page de manuel indique que s'il n'y a pas de fichier ~/.xauth/export et que l'utilisateur invoquant su est root, les cookies ne seront pas transmis aux autres utilisateurs.
Les fichiers ~/xauth/import et ~/.xauth/export doivent être non vides, et contenir une liste d'utilisateurs à raison d'un utilisateur par ligne, avec éventuellement une utilisation des wildcards (le traitement des noms d'utilisateurs dans pam_xauth.c utilise fnmatch(3) dont la syntaxe reconnue est spécifiée dans glob(7)).
Les fichiers de configuration sont les suivants :
- ~/.xauth/import
- ~/.xauth/export
Types de modules : session.
3. Classification des modules par thème
Ce paragraphe propose une catégorisation possible des modules décrits précédemment.
3.1. Authentification et identification
- pam_deny : Refus systématique pour verrouillage de pile PAM,
- pam_localuser : Vérification de l'existence de l'utilisateur dans /etc/passwd,
- pam_permit : Acceptation systématique (souvent pour tests),
- pam_rootok : Vérification du fait que l'UID de l'utilisateur est 0,
- pam_unix : Authentification standard via /etc/passwd et /etc/shadow,
- pam_userdb : Authentification via une base de données Berkeley DB.
3.2. Authentification forte et multi-facteurs
- pam_duo : Authentification via le service Duo Security,
- pam_fprintd : Authentification par empreinte digitale,
- pam_google_authenticator : OTP (One-Time Password) via l'app Google,
- pam_ssh_agent_auth : Authentification via des clés SSH distantes.
3.3. Contrôle d'accès et restrictions
- pam_access : Contrôle basé sur le fichier /etc/security/access.conf (user/host),
- pam_geoip : Restrictions basées sur la localisation géographique de l'IP,
- pam_group : Attribution de groupes secondaires lors de la session,
- pam_listfile : Autorisation/refus selon le contenu d'un fichier arbitraire,
- pam_newnet : Isolation de la session dans un namespace réseau privé,
- pam_nologin : Refus de connexions si /etc/nologin existe (sauf pour root),
- pam_securetty : Restriction de root à certains terminaux sûrs,
- pam_shells : Vérification de l'existence du shell de l'utilisateur dans /etc/shells,
- pam_succeed_if : Contrôle de flux grâce à l'évaluation de conditions (UID, shell, etc.),
- pam_time : Restrictions basées sur l'heure et le jour, le login et le TTY,
- pam_usernet : Assignation d'un namespace réseau à l'utilisateur du groupe usernet,
- pam_wheel : Restreint l'usage aux membres du groupe wheel.
3.4. Gestion des politiques de mots de passe
- pam_pwhistory : Refus de réutilisation d'anciens mots de passe,
- pam_pwquality : Vérification de la robustesse du mot de passe.
3.5. Préparation et environnement de session
- pam_env : Définition de variables d'environnement (attention aux pièges !!!),
- pam_keyinit : Gestion des trousseaux de clés (keyrings) du noyau,
- pam_limits : Application des limites de ressources (système limits.conf),
- pam_mkhomedir : Création du répertoire personnel s'il n'existe pas,
- pam_namespace : Configuration des espaces de noms (poly-instanciation de répertoires),
- pam_systemd : Intégration avec systemd (gestion des sessions et cgroups),
- pam_umask : Définition du masque de création de fichiers,
- pam_xauth : Transmission des cookies d'authentification X11.
3.6. Information et communication utilisateur
- pam_echo : Affichage d'un message textuel arbitraire à l'utilisateur,
- pam_issue : Affichage d'une chaîne devant le prompt login (déprécié),
- pam_lastlog : Affichage de la date de dernière connexion (et verrouillage éventuel),
- pam_mail : Information sur l'existence de nouveaux e-mails,
- pam_motd : Affichage du Message Of The Day.
3.7. Sécurité avancée et audit
- pam_cap : Gestion des capabilities Linux,
- pam_faildelay : Ajout d'un délai après un échec d'authentification,
- pam_faillock : Verrouillage d'un compte après plusieurs échecs,
- pam_loginuid : Définition de l'identifiant d'utilisateur (pour auditd),
- pam_sepermit : Gestion des connexions en fonction de la politique SELinux,
- pam_tty_audit : Activation / désactivation de l'audit des frappes TTY par le noyau,
- pam_warn : Enregistrement d'informations dans syslog.
3.8. Automatisation et scripts externes
- pam_exec : Exécution d'une commande externe,
- pam_filter : Filtrage des flux d'entrée/sortie de la session,
- pam_script : Exécution de scripts lors des phases PAM.
3.9. Modules spécifiques (divers)
- pam_debug : Simulation des codes de retour des fonctions PAM pour la mise au point,
- pam_ftp : Authentification spécifique pour les services FTP anonymes,
- pam_rhosts : Authentification via les fichiers .rhosts (obsolète/non sécurisé),
- pam_setquota : Application de quotas disque au moment de la session,
- pam_stress : Test de l'infrastructure via des simulations de conversations,
- pam_timestamp : Mémorisation d'une authentification réussie pendant un temps donné,
- pam_usertype : Distinction entre utilisateurs système et utilisateurs normaux.
Conclusion
Il existe un grand nombre de modules PAM, pas toujours très bien documentés, et pas toujours présents dans les packages des distributions standard. Leur documentation est souvent succincte, et parfois obsolète. Leur intégration dans une configuration applicative nécessite généralement quelques ajustements, mais lorsqu'elle est au point, les ajouts fonctionnels qu'elle procure sont souvent très appréciables, et on constate que le temps passé à la compréhension de son fonctionnement a été utilement investi.
Cet article, bien que non exhaustif, devrait faciliter la recherche des modules dont on peut avoir besoin et rendre la configuration plus facile.
Un dernier rappel est nécessaire avant de poursuivre l'exploration du sujet : il ne faut pas oublier pas que PAM est un logiciel de sécurité, et qu'à ce titre il est primordial de tester intensivement les configurations mises en place et les éventuels modules développés de façon à ne pas introduire de faille(s) de sécurité. Le cas échéant, il sera peut-être nécessaire d'intégrer PAM dans un contexte SELinux ou AppArmor (qu'il nous est impossible de décrire dans cet article) et d'effectuer une surveillance avec Auditd et un SIEM (Security Information and Event Management) : la sécurité des SI est un sujet sérieux qu'il faut traiter sérieusement.