 |
 |
|
|
L'API PAM fournit six primitives d'authentification diff�rentes regroup�es dans quatre m�canismes qui seront d�crits dans la partie suivante.
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.
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.
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...
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�.
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.
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.
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.
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 :
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.
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.
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.
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.
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.
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.
Ce document, ainsi que d'autres peut �tre t�l�charg� sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions � propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:11