• Objet : Apprendre qu'est-ce que PAM(Pluggable Authentication Modules) et comment le configurer
• Niveau requis :

  avisé
• Commentaires : La modiifcation de PAM ne se fait que sur des machines de type serveur ou pour les acharnés de la sécurité, les options par defaut de Debian conviennent à n'importe quel usager lambda
• Suivi :

  en-chantier, à-tester, à-placer
  • Création par greenmerlin 26/01/2016
  • Testé par <…> le <…>
• Commentaires sur le forum : Lien vers le forum concernant ce tuto ¹⁾

Nota :

Contributeurs, les sont là pour vous aider, supprimez-les une fois le problème corrigé ou le champ rempli !

Pam est un système de bibliothèques qui récupère les “processus d'authentification” des services et applications du système. Peu connu il n'est pas moins utilisé sur beaucoup de distributions, c'est une couche massive de sécurité.

Ce système de bibliothèques “garantit” l'utilisation des commandes d'administration.

Pam à configurer : Le concept est plutôt simple, un fichier par programme ou daemon.
Bien entendu les développeurs de Jessie nous ont tout bien configuré comme il faut

ls /etc/pam.d/

pour un petit aperçu. les plus importants sont :

• /etc/pam.d/common-auth
• /etc/pam.d/common-account
• /etc/pam.d/common-password
• /etc/pam.d/common-session

ldd /bin/vers_le_programme | grep libpam

common-password

...
# here are the per-package modules (the "Primary" block)
password        [success=1 default=ignore]      pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password        requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password        required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
...

Ici la première chose à noter c'est que la syntaxe employée est toujours de type :

Chronologiquement une action PAM se déroule comme il suit :

1. L'utilisateur rentre son nom de connexion et mot de passe
2. Le programme login traite la demande puis délègue l'authentification à PAM
3. PAM lit le fichier /etc/pam.d/login et exécute les directives et renvoie au programme

Décortiquons la ligne :

password        [success=1 default=ignore]      pam_unix.so obscure sha512

Ici le module est pam_unix.so, ce qui signifie que pam va vérifier la concordance avec les fichiers /etc/passwd et /etc/shadow

Pour Success = 1 et default = ignore c'est un peu plus compliqué j'aborderai ça plus loin

Les Options obscure et sha512 signifient que le module va respectivement tester si votre niveau de complexité de mot de passe est suffisant et que le mot de passe sera crypté avec l'algorithme SHA512

Pour bien comprendre les mécanismes de PAM nous allons reprendre notre tableau, mais avant il est nécessaire d'aborder un autre point concernant les fichiers de configuration (/etc/pam.d/*)

Prenons l'exemple suivant :

auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_env.so
auth       sufficient   /lib/security/pam_rootok.so
auth       required     /lib/security/pam_unix.so

Voila comment PAM va interpréter :

Le module “pam_securetty” va vérifier son fichier de configuration, /etc/securetty, afin de vérifier que le terminal utilisé est listé dans le fichier. Si cela n'est pas le cas, les connexions en tant qu'utilisateur root ne seront pas permises.
Vu que le statut est à “required”, le module appelera les trois autres modules de la pile mais même si tous les autres sont ok, la connexion échouera. Notons que si le module avait le statut “requisite”, l'opération aurait été soldée par un échec et aucun des autres modules n'aurait été invoqué, peu importe leur statut.

Le module “pam_env” va fixer les variables d'environnement d'après le fichier /etc/security/pam_env.conf.

Le module “pam_rootok” va verifier si l'utilisateur est root. Si cela échoue, l'opération peut réussir tout de même si le module “pam_unix” authentifie l'utilisateur. Si “pam_rootok” authentifie l'utilisateur, “pam_unix” ne sera pas invoqué.

Le module “pam_unix” essaiera d'authentifier l'utilisateur en utilisant les appels système getpw*. Si “pam_unix” échoue et que “pam_rootok” avait échoué, l'opération échouera. Si “pam_rootok” échoue mais “pam_unix” est correct, l'opération sera exécutée.

Quatre structures de gestion possibles :

• authentification : ceci permet à l'utilisateur de s'authentifier et de définir les droits du compte. Les modules utilisant ce système demandent en général un mot de passe.
• gestion de compte : permet la gestion des comptes utilisateurs. Par exemple, des restrictions peuvent être définies selon les horaires ou la charge du serveur.
• gestion de session : Ce sont les tâches à effectuer en début et fin de chaque session. Par exemple, démarrer un agent ssh, monter des disques cryptés, etc …
• gestion des mots de passe : mise à jour du jeton d'authentification du compte d'un utilisateur, soit parce qu'il a expiré, soit parce que celui-ci désire le modifier.

Que doit faire la librairie PAM en cas de réussite ou d'échec du module ?

plusieurs possibilités :

• required : si un module “required” retourne un statut qui n'est pas “success”, l'opération échouera mais seulement après que tous les modules en dessous soient invoqués. La réussite d'au moins un des modules “required” est nécessaire.
• requisite : si un module “requisite” échoue, l'application en est tout de suite informée et aucun autre module n'est invoqué. La réussite de tous les modules “requisite” est nécessaire.
• sufficient : la réussite d'un seul module “sufficient” est suffisant. Tous les modules “sufficient” qui suivent ne seront pas invoqués. Il faut noter, toutefois, que si un module “required” échoue avant un “sufficient”, l'opération échouera ignorant les autres modules “sufficient”.
• optional : la réussite d'au moins un des modules “optional” est nécessaire si aucun autre n'a réussi.

Une syntaxe un peu plus complète peut-être employée sous la forme de : value=action pairs

[success=1 default=ignore]

success=1 : Si le module PAM renvoie success, PAM va sauter 1 ligne dans le fichier de config (2 pour 2 lignes,etc…)

default=ignore : Le statut de retour du module, n'influencera pas le reste des règles dans le fichier de config

On va faire un exemple ça vaut mieux que les grands discours il parait.

Modifions le comportement par defaut d'un programme en utilisant d'autres modules

Ici on va utiliser le module pam-dbus, sur le programme sshd (OPEN-SSH)

On se logue sous X en graphique (dbus fonctionne avec le mode graphique)

On installe le module pam (oui il n'est pas installé par défaut :p)

apt install libpam-dbus

on édite le fichier /etc/pam.d/sshd

vi /etc/pam.d/sshd

et on remplace la ligne suivante :

@include common-auth

par

auth required pam_dbus.so

ssh localhost

Résultat : http://pix.toile-libre.org/?img=1453979480.png

Ici le module pam-dbus va toujours envoyer un message “dbus” au(x) utilisateur(s) connecté(s) localement pour autoriser ou non la connexion ssh à votre machine.

Décortiquons maintenant l'option :

auth required pam_dbus.so 

• auth : Utiliser un module de type Authentifier et Autoriser
• required : Le module renvoie une erreur et rend la main à la prochaine option PAM
• pam-dbus : Le nom du module que j'utilise