Fichiers de configuration PAM

Noms de service PAM

Le nom de service d'une application utilisant un PAM est le nom de son fichier de configuration dans /etc/pam.d. Tout programme utilisant un PAM définit son propre nom de service.

Par exemple, le programme login définit le nom de service login, ftpd ftp, etc.

En général, le nom de service correspond au nom du programme utilisé pour accéder au service et non pas au nom du programme utilisé pour fournir le service.

Modules PAM

Il y a quatre types de module PAM pour contrôler l'accès à un service donné :

• Les modules auth, qui fournissent l'authentification même (en demandant par exemple un mot de passe et en le vérifiant) et établissent des certificats d'identité, tels qu'une inscription à un groupe ou des tickets Kerberos.

• Les modules account, qui se chargent de la vérification nécessaire afin de s'assurer que l'authentification est permise (si le compte est encore valide, si l'utilisateur est autorisé à ouvrir une session à cette heure de la journée, etc.).

• Les modules password, qui sont utilisés pour définir des mots de passe.

• Les modules session, qui sont utilisés après l'authentification d'un utilisateur. Un module session permet à une personne d'utiliser son compte (pour, par exemple, monter son répertoire personnel ou activer sa boîte aux lettres).

Ces modules peuvent être superposés ou placés les uns à la suite des autres de façon à utiliser plusieurs modules à la fois. L'ordre d'une superposition de modules est très important dans le processus d'authentification car il permet à l'administrateur système de demander que de nombreuses conditions soient remplies avant d'accorder l'authentification à un utilisateur.

Par exemple, rlogin utilise normalement un minimum de quatre méthodes d'authentification, les unes à la suite des autres, comme vous pouvez le constater en jetant un coup d'oeil à son fichier de configuration PAM :

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

Avant d'accorder rlogin à un utilisateur, PAM s'assure que /etc/nologin n'existe pas, que l'utilisateur n'essaie pas de se connecter à distance en tant qu'utilisateur root et que toute variable d'environnement peut être chargée. Ensuite, une authentification rhosts réussie doit être faite avant que la connexion ne soit accordée. Si l'authentification rhosts échoue, une authentification standard au moyen d'un mot de passe est lancée.

Il est possible d'ajouter des modules d'authentification enfichables à tout moment et on peut ensuite créer des applications les reconnaissant pour les utiliser. Par exemple, si vous élaborez une méthode de création de mot de passe unique et écrivez un module d'authentification enfichable pour la prendre en charge, tous les programmes reconnaissant les PAM pourront utiliser ce nouveau module et cette méthode de mot de passe à l'instant sans qu'ils n'aient besoin d'être recompilés ou modifiés. Comme vous pouvez l'imaginer, ceci est très utile car vous pouvez combiner (et tester) rapidement des méthodes d'authentification à différents programmes sans devoir les recompiler.

La documentation sur l'écriture de modules est comprise avec le système dans /usr/share/doc/pam—<version-number>.

Indicateurs de contrôle PAM

Lors d'une vérification, tous les modules PAM produisent un résultat qui en indique la réussite ou l'échec. Les indicateurs de contrôle indiquent aux PAM quoi faire de ce résultat. Comme les modules peuvent être mis dans un ordre bien précis, les indicateurs de contrôle vous donnent la possibilité de définir l'importance de certains modules par rapports à ceux qui viennent après eux.

Prenons, encore une fois, l'exemple du fichier de configuration PAM de rlogin :

auth       required     /lib/security/pam_nologin.so
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rhosts_auth.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth

Une fois qu'un type de module a été spécifié, les indicateurs de contrôle décident quelle importance doit être attribuée au module en question en fonction de l'objectif général qui est d'accorder l'accès du programme à un utilisateur.

Quatre types d'indicateurs de contrôle sont définis par la norme PAM :

• Les modules ayant l'indication required doivent être vérifiés avec succès pour que l'authentification soit accordée. Si la vérification d'un module portant l'indication required échoue, l'utilisateur n'en est pas averti tant que tous les modules du même type n'auront pas été vérifiés.

• Les modules ayant l'indication requisite doivent également être vérifiés avec succès pour que l'authentification soit accordée. Cependant, si la vérification d'un de ces modules échoue, l'utilisateur en est averti sur-le-champ au moyen d'un message lui indiquant l'échec du premier module required ou requisite.

• La vérification des modules ayant l'indication sufficient est ignorée en cas d'échec, mais, si la vérification est réussie et qu'aucun module required précédent n'a échoué, aucun autre module de ce type ne sera vérifié et ce type de module sera considéré comme étant vérifié dans l'ensemble.

• Les modules ayant l'indication optional ne sont pas cruciaux pour la réussite ou l'échec de l'authentification de ce type de module. Ils ne jouent un rôle que lorsque aucun autre module de ce type n'a réussi ou échoué. Dans ce cas, le succès ou l'échec d'un module portant l'indication optional détermine l'authentification PAM générale pour ce type de module.

Il existe maintenant pour PAM une syntaxe d'indicateurs de contrôle plus récente qui offre encore plus de contrôle. Veuillez lire les documents PAM qui se trouvent dans /usr/share/doc/pam—<version-number> pour en savoir plus sur cette nouvelle syntaxe.

Chemins d'accès des modules PAM

Les chemins d'accès indiquent à PAM où trouver les modules enfichables à utiliser avec le type de module spécifié. Normalement, le chemin d'accès complet menant au module est indiqué, tel que /lib/security/pam_stack.so. Cependant, si le chemin d'accès complet n'est pas donné (autrement dit, si le chemin d'accès ne commence pas par un /), on considère alors que le module indiqué est situé dans /lib/security, l'emplacement par défaut des modules PAM.

Arguments PAM

PAM utilise des arguments pour passer des informations à un module enfichable pendant le processus d'authentification d'un type de module donné. Ces arguments permettent aux fichiers de configuration PAM de programmes particuliers d'utiliser le même module PAM, mais de différentes façons.

Par exemple, le module pam_userdb.so utilise des fichiers cachés stockés 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 source ouverte conçue pour être utilisée dans de nombreuses applications afin de contrôler différents types d'informations.) Le module prend un argument db qui spécifie le fichier de la base de données à utiliser et qui peut être différent pour divers services.

Donc, la ligne pam_userdb.so dans un fichier de configuration PAM ressemble à ceci (sur une seule ligne):

auth      required  /lib/security/pam_userdb.so db=chemin d'accès/au/fichier

Les arguments non valides sont ignorés et n'ont aucun effet sur la réussite ou l'échec du module PAM. Lorsqu'un argument non valide est passé, une erreur est généralement écrite dans /var/log/messages. Toutefois, comme la méthode de signalisation est contrôlée par le module PAM, c'est à ce dernier d'enregistrer correctement l'erreur.

Exemples de fichiers de configuration PAM

Un fichier de configuration PAM ressemble à ceci :

#%PAM-1.0
auth      required  /lib/security/pam_securetty.so
auth      required  /lib/security/pam_unix.so shadow nullok
auth      required  /lib/security/pam_nologin.so
account   required  /lib/security/pam_unix.so
password  required  /lib/security/pam_cracklib.so
password  required  /lib/security/pam_unix.so shadow nullok use_authtok
session   required  /lib/security/pam_unix.so

La première ligne est un commentaire (toute ligne commençant par un # est un commentaire). Les lignes deux à quatre superposent trois modules à utiliser pour l'authentification de connexion.

auth      required  /lib/security/pam_securetty.so

La deuxième ligne sert à s'assurer que, si l'utilisateur essaie de se connecter en tant qu'utilisateur root, le terminal sur lequel il se connecte fait partie de la liste se trouvant dans le fichier /etc/securetty, si ce fichier existe.

auth      required  /lib/security/pam_unix.so shadow nullok

La troisième ligne fait en sorte que le mot de passe de l'utilisateur soit demandé et vérifié.

auth      required  /lib/security/pam_nologin.so

La quatrième ligne vérifie si le fichier /etc/nologin existe. Si c'est le cas et que l'utilisateur n'est pas un utilisateur root, l'authentification échoue.

Notez que les trois modules auth sont vérifiés, même si le premier module auth échoue. Cette stratégie empêche que l'utilisateur sache pour quelle raison son authentification n'est pas acceptée. S'il savait pourquoi son authentification est refusée, il pourrait avoir plus de facilité à déjouer le processus d'authentification au prochain essai. Vous pouvez modifier cette méthode en changeant required par requisite. Si un module ayant l'indication requisite obtient un résultat négatif, PAM échoue immédiatement sans appeler d'autres modules.

account   required  /lib/security/pam_unix.so

La cinquième ligne active la vérification des comptes lorsque nécessaire. Par exemple, si des mots de passe masqués ont été activés, le module pam_unix.so vérifie si le compte est périmé ou si l'utilisateur a changé son mot de passe pendant le délai de grâce alloué.

password  required  /lib/security/pam_cracklib.so

La sixième ligne teste les mots de passe récemment modifiés afin de déterminer s'ils peuvent être détectés facilement par un programme de détermination de mots de passe utilisant un dictionnaire.

password  required  /lib/security/pam_unix.so shadow nullok use_authtok

La septième ligne spécifie que le module pam_unix.so doit être utilisé si le programme login change le mot de passe de l'utilisateur. (Cela ne se produit que lorsqu'un module auth détermine que le mot de passe doit être changé — quand un mot de passe masqué est périmé, par exemple.)

session   required  /lib/security/pam_unix.so

La huitième et dernière ligne indique que le module pam_unix.so doit être utilisé pour gérer la session. En ce moment, ce module ne fait rien du tout ; il pourrait être remplacé par tout autre module nécessaire ou complété par la superposition de modules.

Notez que l'ordre des lignes à l'intérieur de chaque fichier compte. Bien que l'ordre dans lequel les modules required sont appelés a peu d'importance, il y a d'autres indicateurs de contrôle disponibles et, alors que optional est rarement utilisé, sufficient et requisite redonnent une importance à l'ordre.

Dans le prochain exemple, nous examinerons la configuration auth de rlogin :

#%PAM-1.0
auth      required    /lib/security/pam_nologin.so
auth      required    /lib/security/pam_securetty.so
auth      required    /lib/security/pam_env.so
auth      sufficient  /lib/security/pam_rhosts_auth.so
auth      required    /lib/security/pam_stack.so service=system-auth

Premièrement, pam_nologin.so vérifie si /etc/nologin existe. S'il existe, seuls les utilisateurs root peuvent obtenir l'accès.

auth      required    /lib/security/pam_securetty.so

Deuxièmement, pam_securetty.so empêche les connexions root sur des terminaux non sécurisés. Ceci a pour effet de refuser toute tentative de rlogin root. Si vous désirez les autoriser (dans ce cas, vous avez intérêt à être protégé par un excellent coupe-feu ou à ne pas être connecté à Internet), lisez la la section intitulée Utilisation de rlogin, rsh et rexec avec PAM.

auth      required    /lib/security/pam_env.so

Troisièmement, le module pam_env.so charge les variables d'environnement spécifiées dans /etc/security/pam_env.conf.

auth      sufficient  /lib/security/pam_rhosts_auth.so

Quatrièmement, si pam_rhosts_auth.so procède à l'authentification de l'utilisateur au moyen de .rhosts dans le répertoire personnel de l'utilisateur, PAM authentifie immédiatement rlogin sans passer à l'authentification normale par mot de passe avec pam_stack.so. Si pam_rhosts_auth.so échoue lors de l'authentification de l'utilisateur, cette tentative non réussie est ignorée.

auth      required    /lib/security/pam_stack.so service=system-auth

Cinquièmement, si pam_rhosts_auth.so ne réussit pas à authentifier l'utilisateur, le module pam_stack.so lance une authentification normale avec mot de passe et l'argument service=system-auth lui est passé.

Remarque

Si vous ne voulez pas qu'une invite de mot de passe apparaisse lorsque la vérification securetty échoue et détermine que l'utilisateur essaie de se connecter à distance comme utilisateur root, vous pouvez changer le module pam_securetty.so de required à requisite. Autrement, si vous désirez autoriser la connexion root à distance (ce qui n'est pas du tout une bonne idée), vous n'avez qu'à mettre un # devant cette ligne pour l'annuler.