PAM : Pluggable Authentication Modules

Lorsque vous arrivez sur un système de type Unix, il est nécessaire de vous identifier. Une fois chose faite, vous devez vous authentifier, c'est-à-dire prouver votre identité. La forme sous laquelle on rencontre le plus souvent cette identification / authentification est bien sûr la procédure de login (identification) et de mot de passe (authentification).

Pour identifier un utilisateur à son arrivée, le système demande un nom d'utilisateur (login), puis un mot de passe. Ce mot de passe est ensuite crypté, puis comparé avec celui correspondant au login dans la base d'utilisateurs /etc/passwd ou /etc/shadow. Le problème de cette méthode "traditionnelle" est la difficulté de changer la procédure. Prenons par exemple le cas simple selon lequel vous ne souhaitez autoriser les logins du root que sur les deux premières consoles (tty1 et tty2). Vous voilà obligé de modifier les sources des programmes concernés, avec tous les risques que cela comporte.

Heureusement, voici PAM. Les Pluggable Authentication Modules sont destinés à simplifier la vie de l'administrateur système. Ils permettent de changer de manière élégante la politique d'authentification sans avoir à recompiler le moindre programme. La seule chose à faire est de modifier un fichier de configuration.

Modules

Comme son nom l'indique, PAM est constitué de modules. Ainsi, pour chaque type de service, vous pouvez définir le ou les modules de votre choix. Il existe quatre familles de modules :

  • modules auth : ils sont utilisés pour une identification classique (login et mot de passe).
  • modules account : ils ont la charge de vérifier si l'identification est autorisée (expiration de compte, plage horaire de connexion).
  • modules password : comme le nom l'indique, ils sont utilisés pour vérifier les mots de passe.
  • modules session : ils sont utilisés à l'intérieur de la session de l'utilisateur (après l'identification). Ils permettent de contrôler par exemple l'accès aux répertoires home et aux boîtes aux lettres.

    Il est également possible de combiner les modules pour obtenir les effets de son choix avec les services de son choix. Chaque application utilisant PAM définit un service. Ainsi, le programme login utilise le service ... login, ftpd le service ftp, rlogin le service rlogin, etc.

    Configuration

    La plupart des distributions récentes incluent PAM. Pour vérifier si PAM est installé sur votre système, rien de plus simple. Jetez simplement un oeil au répertoire /etc. Si celui-ci contient un sous-répertoire pam.d, contenant lui-même un grand nombre de fichiers, PAM est présent. Si votre répertoire /etc contient un pam.conf mais pas de /etc/pam.d, vous possédez une version plus ancienne de PAM. Le reste de cet article ne sera probablement pas en accord avec votre configuration.

    Dans /etc/pam.d sont placés autant de fichiers qu'il existe de services utilisant PAM sur le système. Voici un exemple de noms de fichiers présents dans le répertoire : chfn, chsh, ftpd, login, other, passwd, ppp, proftpd, rexec, rlogin, rsh, samba, su, sul, sudo, xdm, xlock, xscreensaver. On reconnaît rapidement des noms familiers correspondant à certaines applications. Regardons de près l'un des fichiers, su, par exemple. Celui-ci correspond au service su fourni par la commande du même nom qui permet à un utilisateur quelconque de passer temporairement en root : 

    #%PAM-1.0
auth      sufficient  /lib/security/pam_rootok.so
auth      required    /lib/security/pam_unix.so nullok  # set_secrpc
account   required    /lib/security/pam_unix.so
password  required    /lib/security/pam_unix.so         # strict=false
session   required    /lib/security/pam_unix.so debug   # trace or none

    La première ligne offre une facilité pour le root. Celui-ci n'est pas obligé de fournir un mot de passe (il est vrai que, pour ce service, autoriser le root à devenir root est un peu léger mais ce module s'avère bien pratique pour d'autres services). La seconde ligne définit, grâce au module pam_unix, qu'un mot de passe vide (null) est valide. Les trois dernières lignes définissent les choix concernant l'autorisation d'identification, la vérification du mot de passe et la sécurité de la session. Ajoutons à présent la ligne : 

    auth      sufficient  /lib/security/pam_permit.so

    Le module pam_permit ne fait qu'une seule chose, renvoyer PAM_SUCCESS quand on l'interroge. Ainsi, étant donné qu'on signale que ce module est suffisant (sufficient) pour garantir la sécurité, n'importe quel utilisateur peut utiliser su sans aucun mot de passe (dangereux non ?). Voyons maintenant plus en détail ma syntaxe utilisable dans les fichiers de service. Celle-ci est la suivante : 

    famille    drapeau    module    argument(s)

    Nous avons déjà parlé des familles de modules, nous ne n'y reviendrons donc pas. drapeau indique comment la bibliothèque PAM doit réagir en fonction du résultat retourné par un module. Plus haut, nous avons vu qu'une ligne avec un drapeau sufficient avait la possibilité de définir seule le succès ou l'échec dans l'accès au service. Il existe trois autres drapeaux :

  • required : indique que le succès du module est nécessaire pour autoriser le service. Les autres lignes du fichier de service sont également lues et ce n'est qu'après que le service est accordé ou non.

  • requisite : idem, mais les tests sont stoppés dès le premier échec. Ceci permet de mettre en place une sécurité accrue dans des milieux "hostiles". Si, par exemple, vous voulez vous assurer que seul tty1 peut être utilisé pour le root, utilisez ce drapeau. Ainsi, un utilisateur sur une autre console n'aura même pas l'occasion d'essayer un mot de passe.

  • optional : comme son nom l'indique, le succès d'un module défini avec ce drapeau n'est pas vital. C'est uniquement en dernier recours que son "avis" sera pris en compte (losque, par exemple, les autres modules retournent PAM_IGNORE).

    Le champ modules doit être complété avec le chemin complet et le nom du module (habituellement /lib/security/pam_*.so). Dernier champ, argument passe des paramètres au module. Il s'agit principalement d'options permettant de garder des traces de l'activité de PAM dans un journal grâce à un appel syslog.

    Quelques modules

    Nous ne listerons pas ici tous les modules existants. En effet, il en existe des dizaines permettant des possibilités quasi infinies.

  • pam_permit : comme nous l'avons vu, celui-ci ne fait aucun test et retourne toujours PAM_SUCCESS (à utiliser avec précaution).
  • pam_rootok : si l'utilisateur possédant l'ID 0 (le root) demande le test, PAM_SUCCESS est retourné. Ainsi, si le root demande l'accès à certains services, il est d'office autorisé.
  • pam_limits : permet d'imposer certaines limites aux utilisateurs, comme par exemple le nombre de processus, le temps CPU, l'espace disque maximum ...
  • pam_unix : c'est la brique de base de l'authentification. Il permet la gestion du compte, l'obsolescence sur mot de passe, le shadowing, ou encore la mise à jour du mot de passe.
  • pam_securetty : permet de définir certaines consoles comme étant "sûres" pour l'accès au root.

    Info

    Si vous êtes intéressé par PAM ou le développement de nouveaux modules, la première source d'information est la documentation de PAM. Celle-ci est répartie en trois manuels (administrateur, développeur de modules, développeur d'applications). Elle est disponible en ligne ou sous forme de fichiers ps sur http://www.kernel.org/pub/linux/libs/pam/.

    Concernant l'utilisation de chaque module, vous devez avoir dans votre répertoire /usr/doc la documentation de PAM comprenant la plupart des informations nécessaires.

    Linux Magazine France n°13 - Janvier 2000