
Prev		Next

2. Termes et conventions

2.1. D�finitions

La terminologie de PAM est plut�t confuse. Ni la publication originale de Samar et Lai, ni la sp�cification XSSO n'ont essay� de d�finir formellement des termes pour les acteurs et les entit�s intervenant dans PAM, les termes qu'ils utilisent (mais ne d�finissent pas) sont parfois trompeurs et ambigus. Le premier essai d'�tablir une terminologie consistante et non ambigu� fut un papier �crit par Andrew G. Morgan (l'auteur de Linux-PAM) en 1999. Bien que les choix de Morgan furent un �norme pas en avant, ils ne sont pas parfait d'apr�s l'auteur de ce document. Ce qui suit, largement inspir� par Morgan, est un essai de d�finir pr�cis�ment et sans ambigu�t� des termes pour chaque acteur ou entit� utilis� dans PAM.

compte: L'ensemble de permissions que le demandeur demande a l'arbitre.
demandeur: L'utilisateur ou l'entit� demandant authentification.
arbitre: L'utilisateur ou l'entit� poss�dant les privil�ges n�cessaires pour v�rifier la requ�te du demandeur ainsi que l'autorit� d'accorder ou de rejeter la requ�te.
cha�ne: Une s�quence de modules qui sera invoqu�e pour r�pondre � une requ�te PAM. La cha�ne comprend les informations concernant l'ordre dans lequel invoquer les modules, les arguments � leur passer et la fa�on d'interpr�ter les r�sultats.
client: L'application responsable de la requ�te d'authentification au nom du demandeur et de receuillir l'information d'authentification n�cessaire.
m�canisme: Il s'agit de l'un des quatre groupes basiques de fonctionnalit�s fournit par PAM : authentification, gestion de compte, gestion de session et mise � jour du jeton d'authentification.
module: Une collection d'une ou plusieurs fonctions impl�mentant un service d'authentification particulier, rassembl�es dans un fichier binaire (normalement chargeable dynamiquement) et identifi� par un nom unique.
r�gles: Le jeu complet de configuration des r�gles d�crivant comment traiter les requ�tes PAM pour un service particulier. Une r�gle consiste normalement en quatre cha�nes, une pour chaque m�canisme, bien que quelques services n'utilisent pas les quatre m�canismes.
serveur: L'application agissant au nom de l'arbitre pour converser avec le client, r�cup�rer les informations d'authentification, v�rifier les droits du demandeur et autoriser ou rejeter la requ�te.
service: Un ensemble de serveurs fournissant des fonctionnalit�s similaires ou li�es et n�cessitant une authentification similaire. Les r�gles de PAM sont d�finies sur un le principe de par-service; ainsi tous les serveurs qui demandent le m�me nom de service seront soumis aux m�mes r�gles.
session: Le contexte dans lequel le service est d�livr� au demandeur par le serveur. L'un des quatre m�canismes de PAM, la gestion de session, s'en occupe exclusivement par la mise en place et le rel�chement de ce contexte.
jeton: Un morceau d'information associ� avec un compte tel qu'un mot de passe ou une passphrase que le demandeur doit fournir pour prouver son identit�.
transaction: Une s�quence de requ�tes depuis le m�me demandeur vers la m�me instance du m�me serveur, commen�ant avec l'authentification et la mise en place de la session et se terminant avec le d�montage de la session.

2.2. Exemples d'utilisation

Cette section a pour but d'illustrer quelques-uns des termes d�finis pr�c�demment � l'aide d'exemples basiques.

2.2.1. Client et serveurs ne font qu'un

Cet exemple simple montre alice utilisant su(1) pour devenir root.

% whoami
alice
% ls -l `which su`
-r-sr-xr-x  1 root  wheel  10744 Dec  6 19:06 /usr/bin/su
% su -
Password: xi3kiune
# whoami
root

Le demandeur est alice.
Le compte est root.
Le processus su(1) est � la fois client et serveur.
Le jeton d'authentification est xi3kiune.
L'arbitre est root, ce qui explique pourquoi su(1) est setuid root.

2.2.2. Client et serveur sont distincts.

L'exemple suivant montre eve essayant d'initier une connexion ssh(1) vers login.exemple.com, en demandant � se logguer en tant que bob. La connexion r�ussit. Bob aurait du choisir un meilleur mot de passe !

% whoami
eve
% ssh bob@login.example.com
bob@login.example.com's password: god
Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
    The Regents of the University of California.  All rights reserved.
FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001

Welcome to FreeBSD!
%

Le demandeur est eve.
Le client d'eve est repr�sent� par les processus ssh(1)
Le serveur est le processus sshd(8) sur login.example.com
Le compte est bob.
Le jeton d'identification est god.
Bien que cela ne soit pas montr� dans cet exemple, l'arbitre est root.

2.2.3. Exemple de r�gles

Les lignes qui suivent sont les r�gles par d�faut de sshd:

sshd   auth        required    pam_nologin.so  no_warn
sshd    auth        required    pam_unix.so no_warn try_first_pass
sshd    account     required    pam_login_access.so
sshd    account     required    pam_unix.so
sshd    session     required    pam_lastlog.so  no_fail
sshd    password    required    pam_permit.so

Cette politique s'applique au service sshd (qui n'est pas nec�ssairement restreind au serveur sshd(8))
auth, account, session et password sont des m�canismes.
pam_nologin.so, pam_unix.so, pam_login_access.so, pam_lastlog.so et pam_permit.so sont des modules. Il est clair dans cet exemple que pam_unix.so fournit au moins deux m�canismes ( authentification et gestion de compte).

2.3. Conventions

Cette section n'a pas encore �t� �crite.