Pluggable Authentication Modules (PAM)

Pluggable Authentication Modules (modules d’authentification enfichables, en abrégé PAM) est un mécanisme permettant d’intégrer différents schémas d’authentification de bas niveau dans une API de haut niveau, permettant de ce fait de rendre indépendants du schéma les logiciels réclamant une authentification.

PAM est une création de Sun Microsystems et est supporté en 2006 sur les architectures Solaris, Linux, FreeBSD, NetBSD, AIX et HP-UX.

L’administrateur système peut alors définir une stratégie d’authentification sans devoir recompiler des programmes d’authentification. PAM permet de contrôler la manière dont les modules sont enfichés dans les programmes en modifiant un fichier de configuration.

Les programmes qui donnent aux utilisateurs un accès à des privilèges doivent être capables de les authentifier. Lorsque vous vous connectez sur le système, vous indiquez votre nom et votre mot de passe. Le processus de connexion vérifie que vous êtes bien la personne que vous prétendez être. Il existe d’autres formes d’authentification que l’utilisation des mots de passe, qui peuvent d’ailleurs êtres stockés sous différentes formes.

PAM s’interface entre l’utilisateur et le service demandé. Cette couche intermédiaire permet de manipuler de manière cohérente les politiques d’authentification en appelant des modules qui sont des librairies (fichiers .so)

Les modules PAM sont des bibliothèques dynamiques (par ex. pam_unix.so) fournissant les six primitives d’authentification définies dans la norme, regroupées dans quatre types :

  • Le mécanisme account fournit une seule primitive : il vérifie si le compte demandé est disponible (si le compte n’est pas arrivé à expiration, si l’utilisateur est autorisé à se connecter à cette heure de la journée, etc.).
  • Le mécanisme auth fournit deux primitives ; il assure l’authentification réelle, éventuellement en demandant et en vérifiant un mot de passe, et il définit des « certificats d’identité » tels que l’appartenance à un groupe ou des « tickets » kerberos.
  • Le mécanisme password fournit une seule primitive : il permet de mettre à jour le jeton d’authentification (en général un mot de passe), soit parce qu’il a expiré, soit parce que l’utilisateur souhaite le modifier.
  • Le mécanisme session fournit deux primitives : mise en place et fermeture de la session. Il est activé une fois qu’un utilisateur a été autorisé afin de lui permettre d’utiliser son compte. Il lui fournit certaines ressources et certains services, par exemple en montant son répertoire personnel, en rendant sa boîte aux lettres disponible, en lançant un agent ssh, etc.

Source : https://fr.wikipedia.org/wiki/Pluggable_Authentication_Modules

1. Fichiers de configuration des applications PAM

Les fichiers de configuration des différentes applications peuvent être observés :

ls -l /etc/pam.d/
total 100
-rw-r--r--. 1 root root 192  2 aoû 19:12 chfn
-rw-r--r--. 1 root root 192  2 aoû 19:12 chsh
-rw-r--r--. 1 root root 232 18 aoû  2015 config-util
-rw-r--r--. 1 root root 293 31 mar 17:09 crond
lrwxrwxrwx. 1 root root  19  9 jun 19:29 fingerprint-auth -> fingerprint-auth-ac
-rw-r--r--. 1 root root 702  9 jun 19:29 fingerprint-auth-ac
-rw-r--r--. 1 root root 796  2 aoû 19:12 login
-rw-r--r--. 1 root root 154 18 aoû  2015 other
-rw-r--r--. 1 root root 188 10 jun  2014 passwd
lrwxrwxrwx. 1 root root  16  9 jun 19:29 password-auth -> password-auth-ac
-rw-r--r--. 1 root root 974  9 jun 19:29 password-auth-ac
-rw-r--r--. 1 root root 155 23 jun 20:12 polkit-1
lrwxrwxrwx. 1 root root  12  9 jun 19:29 postlogin -> postlogin-ac
-rw-r--r--. 1 root root 330  9 jun 19:29 postlogin-ac
-rw-r--r--. 1 root root 144 10 jun  2014 ppp
-rw-r--r--. 1 root root 681  2 aoû 19:12 remote
-rw-r--r--. 1 root root 143  2 aoû 19:12 runuser
-rw-r--r--. 1 root root 138  2 aoû 19:12 runuser-l
lrwxrwxrwx. 1 root root  17  9 jun 19:29 smartcard-auth -> smartcard-auth-ac
-rw-r--r--. 1 root root 752  9 jun 19:29 smartcard-auth-ac
lrwxrwxrwx. 1 root root  25  9 jun 19:27 smtp -> /etc/alternatives/mta-pam
-rw-r--r--. 1 root root  76 10 jun  2014 smtp.postfix
-rw-r--r--. 1 root root 904 21 mar  2016 sshd
-rw-r--r--. 1 root root 540  2 aoû 19:12 su
-rw-r--r--. 1 root root 202 31 mar 19:09 sudo
-rw-r--r--. 1 root root 187 31 mar 19:09 sudo-i
-rw-r--r--. 1 root root 137  2 aoû 19:12 su-l
lrwxrwxrwx. 1 root root  14  9 jun 19:29 system-auth -> system-auth-ac
-rw-r--r--. 1 root root 974  9 jun 19:29 system-auth-ac
-rw-r--r--. 1 root root 129 15 sep 16:28 systemd-user
-rw-r--r--. 1 root root  84  6 mar  2015 vlock

Syntaxe d’un fichier de configuration :

service type stratégie module arguments

Par exemple /etc/pam.d/login :

cat /etc/pam.d/login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       substack     system-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    include      postlogin
-session   optional     pam_ck_connector.so

Par exemple /etc/pam.d/passwd :

cat /etc/pam.d/passwd
#%PAM-1.0
auth       include	system-auth
account    include	system-auth
password   substack	system-auth
-password   optional	pam_gnome_keyring.so use_authtok
password   substack	postlogin

Par exemple /etc/pam.d/system-auth :

cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Typiquement chaque ligne correspond à un contexte par exemple password prend en charge le changement de mot de passe, applique la stratégie requisite, sufficient puis required avec plusieurs modules et leurs paramètres.

2. Stratégies

Chaque ligne dispose d’une stratégie définie ou renvoit à un ensemble d’autres (include).

  • required : Tous les modules utilisant ce contrôle doivent passer avec succès pour que la vérification soit accordée. Le cas échéant l’utilisateur n’est averti qu’à la fin du traitement de la pile.
  • requisite : Comme required sauf que l’utilisateur est averti immédiatement.
  • optionnal : L’échec ou le succès de ce module importe peu et ne peut faire échouer la vérification.
  • sufficient : S’il réussit et qu’il n’y a pas de required en échec, le traitement s’arrête là. Le reste de la pile n’est alors pas traité.

3. Configuration des modules

Les modules se configurent dans /etc/security/ :

ls -l /etc/security/
total 52
-rw-r--r--. 1 root root 4620 18 aoû  2015 access.conf
-rw-r--r--. 1 root root   82 18 aoû  2015 chroot.conf
drwxr-xr-x. 2 root root    6 18 aoû  2015 console.apps
-rw-r--r--. 1 root root  604 18 aoû  2015 console.handlers
-rw-r--r--. 1 root root  939 18 aoû  2015 console.perms
drwxr-xr-x. 2 root root    6 18 aoû  2015 console.perms.d
-rw-r--r--. 1 root root 3635 18 aoû  2015 group.conf
-rw-r--r--. 1 root root 2422 18 aoû  2015 limits.conf
drwxr-xr-x. 2 root root   26  9 jun 19:26 limits.d
-rw-r--r--. 1 root root 1440 18 aoû  2015 namespace.conf
drwxr-xr-x. 2 root root    6 18 aoû  2015 namespace.d
-rwxr-xr-x. 1 root root 1019 18 aoû  2015 namespace.init
-rw-------. 1 root root    0 18 aoû  2015 opasswd
-rw-r--r--. 1 root root 2972 18 aoû  2015 pam_env.conf
-rw-r--r--. 1 root root 1718  6 déc  2011 pwquality.conf
-rw-r--r--. 1 root root  419 18 aoû  2015 sepermit.conf
-rw-r--r--. 1 root root 2179 18 aoû  2015 time.conf

Comme par exemple le fichier /etc/security/pwquality.conf :

cat /etc/security/pwquality.conf
# Configuration for systemwide password quality limits
# Defaults:
#
# Number of characters in the new password that must not be present in the
# old password.
# difok = 5
#
# Minimum acceptable size for the new password (plus one if
# credits are not disabled which is the default). (See pam_cracklib manual.)
# Cannot be set to lower value than 6.
# minlen = 9
#
# The maximum credit for having digits in the new password. If less than 0
# it is the minimum number of digits in the new password.
# dcredit = 1
#
# The maximum credit for having uppercase characters in the new password.
# If less than 0 it is the minimum number of uppercase characters in the new
# password.
# ucredit = 1
#
# The maximum credit for having lowercase characters in the new password.
# If less than 0 it is the minimum number of lowercase characters in the new
# password.
# lcredit = 1
#
# The maximum credit for having other characters in the new password.
# If less than 0 it is the minimum number of other characters in the new
# password.
# ocredit = 1
#
# The minimum number of required classes of characters for the new
# password (digits, uppercase, lowercase, others).
# minclass = 0
#
# The maximum number of allowed consecutive same characters in the new password.
# The check is disabled if the value is 0.
# maxrepeat = 0
#
# The maximum number of allowed consecutive characters of the same class in the
# new password.
# The check is disabled if the value is 0.
# maxclassrepeat = 0
#
# Whether to check for the words from the passwd entry GECOS string of the user.
# The check is enabled if the value is not 0.
# gecoscheck = 0
#
# Path to the cracklib dictionaries. Default is to use the cracklib default.
# dictpath =

Pour de l’aide, la commande man est toujours utile :

man pam_pwquality

4. Exercice avec check_user

L’objectif est de créer une application qui simule une connexion utilisateur :

Normalement, PAM Check_user est récupéré depuis le dossier examples des sources de PAM.

On trouvera ici les instructions d’installation pour Centos.

4.1. Prérequis

Installez les librairies PAM Devel :

sudo yum install -y pam-devel

Installez les utilitaires de compilation :

sudo yum groupinstall -y 'Development Tools'

4.2. Récupérez les sources

Installez Git:

sudo yum -y install git

Clonez ce dépôt

git clone https://github.com/humboldtux/check_user.git /tmp/check_user

4.3. Compilation

cd /tmp/check_user
gcc -o check_user -lpam -lpam_misc -ldl check_user.c

Un binaire check_user a été créé dans le dossier courant. Vous pouvez vérifier qu’il supporte bien PAM :

ldd check_user

Vous pouvez ensuite copier le binaire dans un dossier de votre $PATH :

sudo mv check_user /usr/sbin/

Puis vérifier que le binaire est bien accessible :

command -v check_user

4.4. Nettoyage

cd
rm -rf /tmp/check_user

4.5. Sans fichier de configuration

check_user user
Not Authenticated

Une application non définie voit son sort réglé par /etc/pam.d/other :

cat /etc/pam.d/other
#%PAM-1.0
auth     required       pam_deny.so
account  required       pam_deny.so
password required       pam_deny.so
session  required       pam_deny.so

4.6. Création d’un fichier de configuration PAM pour checkuser

Création du fichier /etc/pam.d/check_user :

auth required pam_unix.so
account required pam_unix.so

5. Test de stratégies avec le module rps

Documentation du module “rps”. On trouvera ici les instructions pour Centos 6.X+.

5.1. Prérequis

Avoir installé les prérequis de la page https://github.com/humboldtux/check_user.

5.2. Récupérez les sources

Clonez le dépôt :

cd
git clone https://github.com/humboldtux/pam_rps /tmp/pam_rps

5.3. Compilation

cd /tmp/pam_rps/src/
gcc -fPIC -c pam_rps.c
gcc -shared -o pam_rps.so pam_rps.o -lpam

5.4. Installation

Un module pam_rps a été créé dans le dossier courant.

Vous pouvez copier dans le dossier des modules PAM de votre système :

sudo mv pam_rps.so /lib64/security/

Ainsi que la page de manuel :

gzip pam_rps.8.in -c | sudo tee /usr/share/man/man8/pam_rps.8.gz
man pam_rps

5.5. Ménage

cd
rm -rf /tmp/pam_rps

5.6. Stratégie sufficient

cat /etc/pam.d/check_user
auth sufficient pam_rps.so
auth required pam_unix.so
account required pam_unix.so

Test :

check_user user

5.7. Stratégie requisite

cat /etc/pam.d/check_user
#auth sufficient pam_rps.so
auth requisite pam_rps.so
auth required pam_unix.so
account required pam_unix.so

Test :

check_user user

5.8. Autoriser un service

cat /etc/pam.d/check_user
auth sufficient pam_permit.so
auth required pam_unix.so
account required pam_unix.so

5.9. Interdire un service

cat /etc/pam.d/check_user
auth sufficient pam_deny.so
auth required pam_unix.so
account required pam_unix.so

5.10. Configuration de modules

  • /etc/security/time.conf
  • /etc/security/access.conf
  • /etc/security/limits.conf
  • /etc/security/pwquality.conf