
Prev		Next

3. Les bases de PAM

3.1. Mécanismes et primitives

L'API PAM fournit six primitives d'authentification différentes regroupées dans quatre mécanismes qui seront décrits dans la partie suivante.

auth

Authentification. Ce mécanisme concerne l'authentification du demandeur et établit les droits du compte. Il fournit deux primitives :

pam_authenticate(3) authentifie le demandeur, généralement en demandant un jeton d'identification et en le comparant a une valeur stockée dans une base de données ou obtenue par le biais d'un serveur d'authentification.
pam_setcred(3) établi les paramètres du compte tel que l'uid, les groupes dont le compte fait parti ou les limites sur l'utilisation des ressources.

account

Gestion de compte. Ce mécanisme concerne la disponibilité du compte pour des raisons autres que l'authentification. Par exemple les restrictions basées sur l'heure courante ou la charge du serveur. Il fournit une seule primitive:

pam_acct_mgmt(3) vérifie que le compte demandé est disponible.

session

Gestion de session. Ce mécanisme concerne la mise en place de la session et sa terminaison, par exemple l'enregistrement de la session dans les journaux. Il fournit deux primitives:

pam_open_session(3) accomplie les tâches associées à la mise en place d'une session : ajouter une entrée dans les bases utmp et wtmp, démarrer un agent SSH...
pam_close_session(3) accomplie les tâches associées à la terminaison d'une session : ajouter une entrée dans les bases utmp et wtmp, arrêter l'agent SSH...

password

Gestion des mots de passe. Ce mécanisme est utilisé pour modifier le jeton d'authentification associé à un compte, soit parce qu'il a expiré, soit parce que l'utilisateur désire le changer. Il fournit une seule primitive:

pam_chauthtok(3) modifie le jeton d'authentification, et éventuellement vérifie que celui-ci est assez robuste pour ne pas être deviné facilement ou qu'il n'a pas déjà utilisé.

3.2. Modules

Les modules sont le concept clef de PAM; après tout ils constituent le “M” de PAM. Un module PAM est lui-même un morceau de code qui implémente les primitives d'un ou plusieurs mécanismes pour une forme particulière d'authentification; par exemple, les bases de mots de passe UNIX que sont NIS, LDAP et Radius.

3.2.1. Nom des modules

FreeBSD implémente chaque mécanismes dans un module distinct nommé pam_mécanisme.so (par exemple pam_unix.so pour le mechanisme Unix .) Les autres implementations possèdent parfois des modules séparés pour des mécanismes séparés et incluent aussi bien le nom du service que celui du mécanisme dans le nom du module. Un exemple est le module pam_dial_auth.so.1 de Solaris qui est utilisé pour authentifier les utilisateurs dialup.

3.2.2. Gestion des versions de module

L'implementation originale de PAM par FreeBSD, basée sur Linux-PAM, n'utilisait pas de numéro de version pour les modules PAM. Ceci peut poser des problèmes avec les applications tiers qui peuvent être liées avec d'anciennes bibliothèques systèmes, puisqu'il n'y a pas possibilité de charger la version correspondante du module désiré.

Pour sa part, OpenPAM cherche les modules qui ont la même version que la bibliothèque PAM (pour le moment 2) et se rabat sur un module sans version si aucun module avec version n'a put être chargé. Ainsi les anciens modules peuvent être fournis pour les anciennes applications, tout en permettant aux nouvelles applications (ou bien nouvellement compilées) de tirer parti des modules les plus récents.

Bien que les modules PAM de Solaris possèdent généralement un numéro de version, ils ne sont pas réellement versionnés car le numéro correspond à une partie du nom du module et doit être inclus dans la configuration.

3.3. Chaînes et politiques

Lorsqu'un serveur initie une transaction PAM, la bibliothèque PAM essaie de charger une politique pour le service spécifié dans l'appel a pam_start(3) . La politique indique comment la requête d'authentification doit être traitée et est définie dans un fichier de configuration. Il s'agit de l'autre concept clef de PAM : la possibilité pour l'administrateur de configurer la politique de sécurité d'un système en éditant simplement une fichier texte.

Une politique consiste en quatre chaînes, une pour chacune des quatre mécanismes de PAM. Chaque chaîne est une suite de règles de configuration, chacune spécifiant un module à invoquer, des paramètres, options, à passer au module et un drapeau de contrôle qui décrit comment interpréter le code de retour du module.

Comprendre le drapeau de contrôle est essentiel pour comprendre les fichiers de configuration de PAM. Il existe quatre drapeaux de contrôle différents :

binding

Si le module réussit et qu'aucun module précédent de la chaîne n'a échoué, la chaîne s'interrompt immédiatement et la requête est autorisée. Si le module échoue le reste de la chaîne est exécuté, mais la requête est rejetée au final.

Ce drapeau de contrôle a été introduit par Sun Solaris dans la version 9 (SunOS 5.9); il est aussi supporté par OpenPAM.

required

Si le module réussit, le reste de la chaîne est exécuté, et la requête est autorisée si aucun des autres modules n'échoue. Si le module échoue, le reste de la chaîne est exécuté, mais au final la requête est rejetée.

requisite

Si le module réussit le reste de la chaîne est exécuté, et la requête est autorisée sauf si d'autres modules échoués. Si le module échoue la chaîne est immédiatement terminée et la requête est rejetée.

sufficient

Si le module réussit et qu'aucun des modules précédent n'a échoué la chaîne est immédiatement terminée et la requête est allouée. Si le module échoue il est ignore et le reste de la chaîne est exécuté.

Puisque la sémantique de ce drapeau peut être un peu confuse, spécialement lorsqu'il s'agit de celui du dernier module de la chaîne, il est recommandé d'utiliser le drapeau binding à la place de celui-ci sous la condition que l'implementation le supporte.

optional

Le module est exécuté mais le résultat est ignoré. Si tout les modules de la chaîne sont marqués optional, toutes les requêtes seront toujours acceptées.

Lorsqu'un serveur invoque l'une des six primitives PAM, PAM récupère la chaîne du mécanisme à laquelle la requête correspond et invoque chaque module de la chaîne dans l'ordre indiqué, jusqu'à ce que la fin soit atteinte ou qu'aucune exécution supplémentaire ne soit nécessaire (soit à cause du succès d'un module en binding ou sufficient, soit à cause de l'échec d'un module requisite). La requête est acceptée si et seulement si au moins un module a été invoqué, et que tout les modules non optionnels ont réussi.

Notez qu'il est possible, bien que peu courant, d'avoir le même module listé plusieurs fois dans la même chaîne. Par exemple un module qui détermine le nom utilisateur et le mot de passe à l'aide d'un serveur directory peut être invoqué plusieurs fois avec des paramètres spécifiant différents serveurs a contacter. PAM considère les différentes occurrences d'un même module dans une même chaîne comme des modules différents et non liés.

3.4. Transactions

Le cycle de vie d'une transaction PAM typique est décrit ci-dessous. Notez que si l'une de ces étapes échoue, le serveur devrait reporter un message d'erreur au client et arrêter la transaction.

Si nécessaire, le serveur obtient les privilèges de l'arbitre par le biais d'un mécanisme indépendant de PAM -- généralement en ayant été démarré par root ou en étant setuid root.
Le serveur appel pam_start(3) afin d'initialiser la bibliothèque PAM et indique le service et le compte cible, et enregistre une fonction de conversation appropriée.
Le serveur obtient diverses informations concernant la transaction (tel que le nom d'utilisateur du demandeur et le nom d'hôte de la machine sur lequel le client tourne) et les soumet à PAM en utilisant la fonction pam_set_item(3).
Le serveur appel pam_authenticate(3) pour authentifier le demandeur.
Le serveur appel la fonction pam_acct_mgmt(3) qui vérifie que le compte est valide et disponible. Si le mot de passe est correct mais a expiré, pam_acct_mgmt(3) retournera PAM_NEW_AUTHTOK_REQD à la place de PAM_SUCCESS.
Si l'étape précédente a retourné PAM_NEW_AUTHTOK_REQD, le serveur appel maintenant pam_chauthtok(3) pour obliger l'utilisateur à changer le jeton d'authentification du compte désiré.
Maintenant que le demandeur a été correctement authentifié, le serveur appelle pam_setcred(3) pour obtenir les privilèges du compte désiré. Il lui est possible de faire ceci parce qu'il agit au nom de l'arbitre dont il possède les privilèges.
Lorsque les privilèges corrects ont été établi le serveur appelle pam_open_session(3) pour mettre en place la session.
Maintenant le serveur effectue les services demandés par le client -- par exemple fournir un shell au demandeur.
Lorsque le serveur a fini de servir le client, il appelle pam_close_session(3) afin de terminer la session.
Pour finir, le serveur appelle pam_end(3) afin signaler à la bibliothèque PAM que la transaction se termine et qu'elle peut libérer les ressources qu'elle a alloué au cours de la transaction.

Prev	Home	Next
Termes et conventions		Configuration de PAM