PAM (Pluggable Authentification Module) : Choisir ses méthodes d'authentifications

1 Introduction

PAM est LE système d'authentification utilisé en standard sous Linux. La puissance de cet outil est sans limite mais il n'est pas toujours bien documenté ce qui a tendance à le desservir. En guise d'introduction, arrêtons nous tout d'abord sur les motivations qui ont entraîné la création de PAM. A l'origine, sous Unix (et dans les premières versions de Linux), le fichier qui centralisait la gestion des utilisateur était /etc/passwd. Il contenait nombre d'informations sensibles, dont le mot de passe chiffré. Or, pour pouvoir utiliser une machine Unix, la première chose à faire était de s'authentifier via le programme login (dernier programme lancé par init). Ce programme avait donc été développé pour parser le fichier /etc/passwd.

Cependant, avec le temps, on s'est apercu que stoquer les mots de passe utilisateur dans un fichier en lecture pour tout le monde pouvait représenter un trou de sécurité (les machines personnelles étant de plus en plus aptes à effectuer du brute force pour retrouver des mots de passe). Cette constatation a eu pour conséquence la création d'un fichier de mot de passe déporté appelé /etc/shadow.

Seulement, login devait être réimplémenté pour prendre ce changement en considération. Il en était en fait de même pour tous les programmes qui nécessitaient une authentification (ftp, su, sudo...).

Par la suite, on s'est appercu que disposer d'un fichier plat pour l'authentification pouvait représenter une certaine limite lorsque l'on manipulait des dizaines de miliers de comptes. D'autres base de données furent donc été utilisées, telles que les annuaires. L'idée fut révolutionnaire mais le problème était qu'encore une fois, il fallait réécrire certaines parties du code d'authentification des applications concernées.

Ces constatations faites (quelques heures de génie logiciel et quelques centaines de miliers de lignes de code plus tard), les développeurs du noyau Linux ont eu l'idée de déporter toute la couche d'authentification en dehors des programmes en ayant besoin. Ils ont donc créer les Pluggable Authentification Modules.

2 Mode de fonctionnement

Linux PAM est un jeu de bibliothèques dynamiques gérant des points précis du processus d'authentification. Nous verrons ci-après que lorsque nous parlons d'authentification, nous ne nous limitons pas au simple challenge login/mot de passe, mais bien à un ensemble de points d'authorisation pouvant affecter aussi bien l'authentification à proprement parler que les sessions ou la gestion des mots de passe.

Une application peut donc être développée pour se lier dynamiquement à ces bibliothèques et donc accéder à des fonctionnalités déjà implémentées et stables. A ce titre, Linux PAM met à la disposition des développeurs une API détaillée des fonctions disponibles.

Pour information, ces bibliothèques se trouvent généralement dans le répertoire /lib/security.

Du point de vue de l'administrateur système, cela lui permet de configurer le comportement à tenir pour toutes ses applications nécessitant une authentification. La seule restriction étant que l'application soit « PAM enabled », c'est a dire qu'elle soit développée pour utiliser les librairies PAM. Se reporter à la documentation de l'application en cas de doute. L'administrateur peut donc s'il le souhaite définir que pour un service donné (par exemple xdm), l'authentification se fera en 3 étapes distinctes (matérialisées par l'utilisation de 3 bibliothèques dynamiques, donc 3 modules) auquel il passera des arguments de configuration.

Il peut donc choisir exactement sa propre politique d'authentification pour cette application, indépendamment de celle-ci.

Dans la terminologie PAM, configurer une application revient a configurer l'accès au service. Ainsi, si vous installez proftpd ou wuftpd, vous fournirez le service ftp à vos utilisateurs.

Tout les services sont configurés dans le répertoire /etc/pam.d/ où chaque fichier détaille les politiques d'authentification liées à ce service.

3 Hierarchisation des taches d'authentification

Afin de simplifier l'utilisation et la compréhension du rôle de chaque module, les taches d'authentification sont divisées en 4 groupes indépendants :

• Account
• Authentification
• Passwd
• Session

Un service est donc divisé en 4 groupes. A chaque groupe, on assigne un ou plusieurs modules.

Bien qu'en théorie, ces groupes semble bien délimiter chaque tache du processus d'authentification, le lecteur devra garder à l'esprit que pour certains modules, la distinction de l'emplacement du module parmi ces 4 groupes n'est pas toujours aisée, d'autant plus qu'un module peut intervenir dans plusieurs groupes. Pour connaître précisemment les possibilités offertes par un module pour chacun des groupes, il faut lire les docs du dévellopeur du module en question. Généralement, le synopsis de l'utilisation d'un module est fourni dans sa page de man.

Pour résumer:

• Un module est un morceau de code capable d'être lié dynamiquement à une application fournissant un service.
• Un service est configuré dans un fichier (nommé selon son type de service) contenu dans le répertoire /etc/pam.d/
• Un module offre un certain nombre de fonctionnalités qui sont hierarchisées en 4 groupes, définissant leur périmêtre d'action.
• Un module peut fournir des fonctionnalités pour un seul ou plusieurs groupes. Par exemple, le module pam_xauth ne fourni que des fonctionnalités dans le groupe session alors que pam_unix en fourni pour chaque groupe.

4 Exemple d'utilisation de Linux PAM

La première idée qui vient généralement à l'esprit d'un administrateur en matière de sécurité est de définir qui peut accéder physiquement à une machine. Pour cela, nous allons configurer 2 accès :

• login qui sert à se connecter en mode console
• gdm qui sert à se connecter en mode graphique avec l'environnement Gnome (le lecteur utilisera son gestionnaire de session propre, selon l'environnement de travail)

Ces applications étant « PAM enabled », nous pouvons à loisir définir la politique de sécurité que nous désirons.

/etc/pam.d/login

[seb@localhost seb]$ cat /etc/pam.d/login #%PAM-1.0 : login service auth required pam_nologin.so auth required pam_access.so #auth required pam_securetty.so auth required pam_stack.so service=system-auth account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session optional pam_console.so

Comme nous l'avons évoqué précédemment, chaque service (défini par le nom du fichier) utilise des modules (3ème colonne), répartis en groupes (1ère colonne). De même, certains modules peuvent être utilisés plusieurs fois, dans des groupes différents, leur comportement étant différents.

Dans les exemples fournis ci-dessus, nous pouvons voir l'utilisation du module pam_stack dans quasiment tout les groupes d'authentification. Ce module est un peu particulier puisqu'il n'a pour objectif que de renvoyer l'authentification au module passé en argument. Il permet ainsi de définir un comportement commun à beaucoup de services, idéal pour les configurations simples ou homogènes.

Si vous modifiez la configuration du module system-auth, tout les autres modules qui l'utilisent à l'aide de pam_stack seront modifiés.

Un autre point important de la configuration des fichiers de services concerne l'empilement des modules par ordre de lecture. Ainsi, dans l'exemple ci-dessus, dans le groupe d'authentification, le module pam_nologin sera évalué avant le module pam_access, lui même évalué avant pam_stack. Ceci a une importance lorsque l'on considère que l'on peut définir quelle sera la conséquence de la réussite de l'utilisation d'un module.

Nous avons la possibilité de définir 4 type d'obligation de réussite à tenir :

• required
• requisite
• sufficient
• optional

Si l'on synthètise toutes les notions que nous venons d'aborder, la configuration d'une politique de sécurité que l'on applique à un service passe par l'utilisation d'un ou plusieurs modules, renseignés dans un fichier situé dans /etc/pam.d. Dans ce fichier, chaque ligne informe PAM d'utiliser une fonctionnalité d'un module selon le groupe, inscrit en début de ligne (auth,session...).

PAM va lire séquentiellement les lignes de chaque groupe et va confronter l'obligation de réussite définit par l'administrateur (required, requisite...) au code retour renvoyé par la librairie et décider de continuer ou pas, selon le résultat.

Il est important d'indentifier ce qui donne lieu à une intéraction avec l'utilisateur, par exemple un module du type pam_unix.so et ce qui ne fait qu'appliquer un traitement (pam_env) pour fixer le drapeau de contrôle.

Prenons un exemple simple. Imaginons que nous voulions définir le scénario suivant pour l'authentification avec gdm :

• L'utilisateur doit avoir un compte local sur la machine
• Son mot de passe ne doit pas être nul
• Nous souhaitons lui définir des variables d'environnement
• L'utilisateur doit avoir le droit de se logger

Nous nous intérressons donc qu'à la partie authentification, chaque ligne que nous renseignerons seront donc précédées par «auth » :

auth required pam_env.so // Défini l'utilisation des variables d'environnements utilisateurs
auth required pam_unix.so // Utilise la procédure standard d'authentification sous Linux
auth required pam_nologin.so // Il doit faire partie des utilisateur ayant droits de login
auth required pam_deny.so

Lorsque l'utilisateur Boulay va vouloir se logger sur la machine, PAM va vérifier les points suivants : La première entrée de la pile concerne le module pam_env. Celui-ci définit des variables d'environnements renseignée dans le fichier /etc/environnement. A priori, aucune erreur ne peut être générée à ce stade, la lecture de la pile continue.

Le module pam_unix va gérer l'authentification style Unix, c'est à dire qu'il va lire /etc/passwd et /etc/shadow pour valider le challenge login/mot de passe. En plus, nous fournissont en argument que le mot de passe nul n'est pas acceptable. Si Boulay réussi à prouver par ce mécanisme qui il est réellement, PAM va continuer la lecture de la pile.

Le dernier module utilisé pour l'authentification est pam_deny qui ca refuser systèmatiquement la demande de connexion. A priori, comme pour pam_env, le résultat sera toujours valide. Le résultat total de la pile est valide, donc l'utilisateur peut accéder au service. Login va forker et lui executer un shell, lui donnant accès à la machine.

5 Exemple de configuration avancée

Après avoir vu comment s'organise la configuration du comportement de PAM pour un service simple, nous allons ici détailler quelques exemples de configuration pour augmenter significativement la sécurité de certain programme. Par défaut, les distributions accepte que n'importe quel utilisateur puisse demander d'accéder à une session super utilisateur en invoquant la commande su. Pour n'accepter que les utilisateurs membres du groupe wheel, ajouter dans le service su (/etc/pam.d/su) la ligne suivante :

/etc/pam.d/su

auth required pam_wheel.so use_uid

Et comme PAM est modulaire, il va ainsi en être de même pour chaque service. Vous pouvez donc definir que pour tel service, seul les utilisateurs membres du groupe wheel pourront s'authentifier.

Avec l'exemple ci-dessus, on comprend aisément qu'il est désormais très simple d'appliquer des droits d'exécution selon un service et un utilisateur donné. Un des problèmes récurrents sous Unix est l'utilisation de certains programmes C minimalistes pouvant entrainer un disfonctionnement de la machine. Ainsi, comme il est souvent le cas dans les écoles ou universités scientifiques, il arrive que des étudiant utilise le célebre fork Bomb (while(1) fork() ), entrainant la machine dans un déluge de création de processus, ne lui permettant plus de répondre aux actions légitimes.

Le module pam_limits.so permet heureusement de limiter les ressources utilisées par des utilisateurs. Ce module, une fois défini dans le service que l'on souhaite utiliser, doit être configurer, en éditant le fichier /etc/security/limits.conf. Ce module travail dans le groupe session, nous éditons donc /etc/pam.d/{gdm,kdm,login} selon le gestionnaire utilisé :

/etc/pam.d/{gdm,kdm,login}

session required /lib/security/pam_limits.so // Sans arguments, utilise le fichier /etc/security/limits.conf

Puis, en editant le fichier limits.conf :

limits.conf

#<domain> <type> <item> <value> boulay hard fsize 100000 // Défini une taille maximal d'utilisation de disque pour l'utilisateur boulay @etudiant hard nproc 30 // Defini un nombre maximal de processus en cours pour le groupe d'utilisateur etudiant

Ainsi, pendant chaque session l'utilisateur boulay ne pourra pas créer de fichier d'une taille superieure à 10Mo et les etudiant ne pourront pas lancer plus de 30 processus. Attention toutefois aux limites que vous souhaitez définir sachant qu'avec des environnements tel que kde ou gnome, de nombreux processus en tache de fond sont éxécutés...

6 Conclusion

Par sa puissance PAM peut paraître au premier abord assez complexe à utiliser, d'autant qu'une erreur peut rapidement vous empecher d'accéder à votre machine (seul un reboot en single user pourra vous aider dans ce cas). Néanmoins, le nombre important de modules officiels et non officiels <POINTEUR> permettent de rendre les taches d'authentification sous Linux très versatiles. Vous pouvez facilement intégrer une authentification par LDAP, NDS, ou auprès d'un serveur NT ou encore par biométrie sans avoir modifier le code des services.