Pour illustrer la théorie sous-jacente aux modules PAM et en comprendre les rouages, prenez l'exemple pratique suivant de la configuration PAM de sshd :
Exemple 36.1. Configuration PAM de sshd
#%PAM-1.0 auth include common auth auth required pam_nologin.so account include common-account password include common-password session include common-session # Activez la ligne suivante pour obtenir la prise en charge resmgr pour # les sessions ssh (reportez-vous à /usr/share/doc/packages/resmgr/README.SUSE) #session optional pam_resmgr.so fake_ttyname
La configuration PAM type d'une application (sshd, dans le cas présent) contient quatre instructions include qui font référence aux fichiers de configuration de quatre types de modules : common-auth, common-account, common-password et common-session. Ces quatre fichiers détiennent la configuration par défaut de chaque type de module. En incluant ces instructions au lieu d'appeler chaque module séparément pour chaque application PAM, vous obtenez automatiquement la mise à jour d'une configuration PAM si l'administrateur change les paramètres par défaut. Avant, lorsque des modifications étaient apportées aux modules PAM ou qu'une nouvelle application était installée, vous deviez régler tous les fichiers de configuration manuellement pour toutes les applications. Désormais, la configuration PAM s'effectue de façon centralisée via les fichiers de configuration : ainsi, la configuration PAM de chaque périphérique hérite automatiquement du moindre changement.
Le premier fichier include (common-auth) appelle deux modules de type auth : pam_env et pam_unix2. (voir Exemple 36.2, « Configuration par défaut de la section auth »).
Exemple 36.2. Configuration par défaut de la section auth
auth required pam_env.so auth required pam_unix2.so
Le premier module, pam_env, charge le fichier /etc/security/pam_env.conf pour définir les variables d'environnement conformément aux spécifications de ce fichier. Cela peut être utilisé pour définir la valeur appropriée pour la variable DISPLAY. Le module pam_env connaît en effet l'emplacement à partir duquel est exécuté le login. Le deuxième module, pam_unix2, contrôle le login et le mot de passe de l'utilisateur en fonction des informations des répertoires /etc/passwd et /etc/shadow.
Une fois les modules indiqués dans common-auth appelés avec succès, un troisième module, pam_nologin, vérifie si le fichier /etc/nologin existe. S'il existe, seul l'utilisateur root peut se loguer. La totalité de la pile des modules auth est traitée et ce n'est qu'ensuite que sshd est informé de la réussite ou de l'échec du login. Étant donné que tous les modules de la pile portent le drapeau required, ils doivent tous être traités avec succès pour que sshd puisse recevoir un message lui confirmant la réussite de l'opération. En cas d'échec de l'un des modules, le reste de la pile continue à être traité et ce n'est qu'ensuite que sshd est averti de cet échec.
Dès que tous les modules de type auth ont été traités avec succès, une autre instruction include est traitée (dans le cas présent, voir l'Exemple 36.3, « Configuration par défaut de la section account »). common-account ne contient qu'un seul module, pam_unix2. Si pam_unix2 renvoie un résultat indiquant que l'utilisateur existe, sshd reçoit un message de confirmation et la prochaine pile de modules (password) est traitée, comme dans l'Exemple 36.4, « Configuration par défaut de la section password ».
Exemple 36.4. Configuration par défaut de la section password
password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok #password required pam_make.so /var/yp
Une fois encore, la configuration PAM de sshd implique seulement une instruction include faisant référence à la configuration par défaut des modules password dans common-password. Ces modules doivent être exécutés avec succès (drapeau de contrôle required) chaque fois que l'application requiert qu'un jeton d'authentification soit modifié. Le changement d'un mot de passe ou d'un autre jeton d'authentification requiert un contrôle de sécurité. Cette opération est exécutée à l'aide du module pam_pwcheck. Le module pam_unix2 utilisé ensuite reprend les anciens et nouveaux mots de passe dans pam_pwcheck : l'utilisateur n'a donc pas besoin de s'authentifier à nouveau. Ainsi, il est également impossible d'éviter les contrôles menés par pam_pwcheck. Les modules de type password doivent être utilisés chaque fois que les modules précédents de type account ou auth sont configurés pour signaler l'arrivée à expiration d'un mot de passe.
Exemple 36.5. Configuration par défaut de la section session
session required pam_limits.so session required pam_unix2.so
Comme étape finale, les modules de type session, rassemblés dans le fichier common-session, sont appelés pour configurer la session selon les paramètres de l'utilisateur en question. Même si pam_unix2 est à nouveau traité, en pratique, cela n'a pas de conséquence car son option none est indiquée dans pam_unix2.conf, le fichier de configuration correspondant à ce module. Le module pam_limits charge le fichier /etc/security/limits.conf, qui peut définir des limites d'utilisation de certaines ressources système. Les modules session sont appelés une deuxième fois lorsque l'utilisateur se délogue.