16.2. Configuration PAM de sshd

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 16.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
# Enable the following line to get resmgr support for
# ssh sessions (see /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. Reportez-vous à l'Exemple 16.2, « Configuration par défaut de la section auth ».

Exemple 16.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, reportez-vous à l'Exemple 16.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 16.4, « Configuration par défaut de la section password ».

Exemple 16.3. Configuration par défaut de la section account


account required        pam_unix2.so

Exemple 16.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 16.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.