16.3. Format des fichiers de configuration PAM
Chaque fichier de configuration PAM comprend un ensemble de directives établies selon format suivant :
<module interface> <control flag> <module name> <module arguments> |
Les sections suivantes décrivent ces éléments un par un.
16.3.1. Interface du module
Il existe quatre types d'interfaces pour les modules PAM, chacune correspondant à un aspect différent du processus d'autorisation :
auth — Cette interface de module sert à authentifier l'utilisateur. Elle demande par exemple la saisie d'un mot de passe pour lequel elle vérifie la validité. Les modules avec cette interface peuvent également établir des certificats d'identité, tels que l'appartenance à un groupe ou des tickets Kerberos.
account — Cette interface de module sert à vérifier que l'accès est bien autorisé. Par exemple, elle peut vérifier si un compte utilisateur a expiré ou non, ou bien si l'utilisateur est autorisé à se connecter à un moment donné de la journée.
password — Cette interface de module sert à définir et vérifier les mots de passe.
session — Cette interface de module ser à configurer et gérer des sessions d'utilisateurs. Les modules ayant cette interface peuvent également effectuer des tâches supplémentaires requises pour autoriser l'accès, comme par exemple pour monter le répertoire personnel d'un utilisateur ou activer sa boîte aux lettres.
 | Remarque |
|---|---|
Un module individuel peut fournir une interface de module quelconque ou toutes les interfaces de modules. Par exemple, pam_unix.so fournit les quatre interfaces de module. |
Dans un fichier de configuration PAM, le champ relatif à l'interface de module est le premier à être défini. Par exemple, une ligne typique d'un fichier de configuration pourrait ressembler à l'extrait suivant :
auth required pam_unix.so |
Cette ligne donne l'instruction à PAM d'utiliser l'interface auth du module pam_unix.so.
16.3.1.1. Empilage d'interfaces de module
Les directives relatives aux interfaces de modules peuvent être empilées ou placées les unes sur les autres, afin que de multiples modules soient utilisés ensemble dans un but particulier. Dans de telles circonstances, l'ordre dans lequel les modules sont répertoriés est très important au niveau du processus d'authentification.
Grâce à l'empilage, un administrateur peut facilement exiger la présence de différentes conditions avant d'autoriser un utilisateur à s'authentifier. Par exemple, rlogin utilise normalement cinq modules auth empilés, comme le montre son fichier de configuration PAM :
auth required pam_nologin.so auth required pam_securetty.so auth required pam_env.so auth sufficient pam_rhosts_auth.so auth required pam_stack.so service=system-auth |
Avant qu'un utilisateur puisse utiliser rlogin, PAM s'assure que le fichier /etc/nologin n'existe pas, que l'utilisateur n'essaie pas de se connecter à distance en tant que super-utilisateur (ou root) au moyen d'une connexion réseau et que toutes les variables d'environnement peuvent être chargées. Ensuite, si une authentification rhosts est établie avec succès, la connexion est autorisée. En revanche, si l'authentification rhosts n'aboutit pas, une authentification de mot de passe standard est exécutée.
16.3.2. Indicateurs de contrôle
Lorsqu'ils sont appelés, tous les modules PAM donnent un résultat indiquant soit la réussite, soit l'échec. Les indicateurs de contrôle indiquent à PAM la manière de traiter ce résultat. Étant donné que les modules peuvent être empilés dans un ordre bien précis, les indicateurs de contrôle décident de l'importance de la réussite ou de l'échec d'un module spécifique par rapport au but général d'authentification d'un utilisateur pour un service donné.
Il existe quatre types d'indicateurs de contrôle prédéfinis, à savoir :
required — Le module doit être vérifié avec succès pour que l'authentification puisse se poursuivre. Si la vérification d'un module de type required échoue, l'utilisateur n'en est pas averti tant que tous les modules associés à cette interface n'ont pas été vérifiés.
requisite — Le module doit être vérifié avec succès pour que l'authentification puisse se poursuivre. Cependant, si la vérification d'un module de type requisite échoue, l'utilisateur en est averti immédiatement par le biais d'un message lui indiquant l'échec du premier module de types required ou requisite.
sufficient — En cas d'échec, les vérifications de modules sont ignorées. Toutefois, si la vérification d'un module de type sufficient est réussie et qu'aucun module précédent de type required n'a échoué, aucun autre module de ce type n'est nécessaire et l'utilisateur sera authentifié auprès du service.
optional — Les vérifications de modules sont ignorées. Un module de type optional ne devient nécessaire que pour la réussite d'une authentification lorsqu'aucun autre module ne référence l'interface.
 | Important |
|---|---|
L'ordre dans lequel les modules de type required sont appelés n'est pas primordial. Les indicateurs de contrôles sufficient et requisite en revanche, donnent à l'ordre une importance vitale. |
Pour PAM, il existe désormais une nouvelle syntaxe d'indicateurs de contrôle qui offre un contrôle encore plus précis. Veuillez lire la documentation relative à PAM disponible dans le répertoire /usr/share/doc/pam-<version-number>/ (où <version-number> correspond au numéro de version de PAM) pour obtenir des informations sur cette nouvelle syntaxe.
16.3.3. Nom de module
Le nom de module donne à PAM le nom du module enfichable contenant l'interface module spécifiée. Sous les versions plus anciennes de Red Hat Enterprise Linux, le chemin entier du module était fourni dans le fichier de configuration PAM, tel que /lib/security/pam_stack.so. Toutefois, depuis l'arrivée de systèmes multilib qui stockent des modules PAM de 64-octets dans le répertoire /lib64/security/, le nom du répertoire est omis car les applications sont liées à la version appropriée de libpam, qui peut trouver la version correcte du module.
16.3.4. Arguments des modules
PAM utilise des arguments pour transmettre des informations à un module enfichable lors du processus d'authentification de certains modules.
Par exemple, le module pam_userdb.so utilise des indications secrètes stockées dans un fichier de la base de données Berkeley pour authentifier les utilisateurs. La base de données Berkeley est une base de données Open Source intégrée dans de nombreuses applications. Le module nécessite un argument db pour spécifier à la base de données Berkeley la base de données précise devant être utilisée pour le service demandé.
Une ligne pam_userdb.so typique d'un fichier de configuration PAM ressemble à l'extrait suivant :
auth required pam_userdb.so db=<path-to-file> |
Dans l'exemple précédent, remplacez <path-to-file> par le chemin d'accès complet au fichier de la base de données Berkeley DB.
Les arguments non valides ne sont pas pris en compte et n'ont aucune incidence sur la réussite ou l'échec du module PAM. Toutefois, la plupart des modules rapporteront des erreurs dans le fichier /var/log/messages.