7.0 KiB
GDM et PAM
GDM utilise PAM pour l'authentification. Il s'appuie sur une configuration
dédiée dans /etc/pam.d, cf les fichiers de profil gdm-password,
gdm-smartcard et gdm-fingerprint.
Le reste du système (login console, SSH) utilise aussi PAM, via une autre
configuration nommée /etc/pam.d/common-auth. Le contenu de ce fichier
est généré automatiquement par pam-auth-update pour tous les modules PAM
qui livrent une définition dans /usr/share/pam-configs.
Sur Hirstute, dans la configuration par défaut, GDM choisit automatiquement
le profil qu'il va utiliser : si un token PKCS#11 qui possède le drapeau
"amovible" est présent (typiquement le dongle Aladdin), alors il utilisera
le profil gdm-smartcard, sinon il utilisera le profil gdm-password.
Il est possible de changer cette sélection avec une propriété dconf,
comme ceci:
[org/gnome/login-screen]
enable-smartcard-authentication=false
et alors GDM utilise le profil gdm-password, même si un dongle PKI est
connecté à la machine lors de la connexion.
Le profil gdm-password est grosso-modo une façade pour common-auth
(il fait l'inclusion de ce fichier), donc tous les modules PAM qui y sont
déclarés sont utilisables (unix, ccreds, krb5, sss, etc.)
Le profil gdm-smartcard est un lien symbolique, géré par update-alternatives,
qui peut pointer vers l'un des trois profils qui gèrent effectivement les
tokens PKCS#11:
gdm-smartcard-pkcs11-exclusivequi utilise le modulepam_pkcs11gdm-smartcard-sssd-exclusivequi utilise le modulepam_sssavec l'optionrequire_cert_authgdm-smartcard-sssd-or-passwordqui utilise le modulepam_sssavec l'optiontry_cert_authet passe la main au profilcommon-authen solution de secours si le premier module a échoué.
Ces trois profils nécessitent une configuration dédiée pour PKCS#11 dans le module PAM correspondant, si pas configuré, ça ne marche pas : GDM va demander l'identifiant de l'utilisateur (username), puis le PIN, et ensuite l'authentification échoue, retour au point de départ, en boucle.
La valeur par défaut sur Ubuntu est gdm-smartcard-sssd-exclusive.
Selection d'un profil gdm-smartcard
En mode interactif:
$ sudo update-alternatives --config gdm-smartcard
There are 3 choices for the alternative gdm-smartcard (providing /etc/pam.d/gdm-smartcard).
Selection Path Priority Status
0 /etc/pam.d/gdm-smartcard-sssd-exclusive 50 auto mode [*]
1 /etc/pam.d/gdm-smartcard-pkcs11-exclusive 30 manual mode
2 /etc/pam.d/gdm-smartcard-sssd-exclusive 50 manual mode
3 /etc/pam.d/gdm-smartcard-sssd-or-password 40 manual mode
Press to keep the current choice[*], or type selection number: 3
En mode inattendu:
$ sudo update-alternatives --set gdm-smartcard /etc/pam.d/gdm-smartcard-sssd-or-password
Il n'est pas nécessaire de redémarrer le service gdm3 après
modification.
Saisie de l'identifiant utilisateur en mode smartcard
En mode par défaut (gdm-password), l'écran d'accueil GDM présente la
liste des utilisateurs humains (>=1000) déclarés sur la machine, ou bien un
unique utilisateur pré-sélectionné s'il n'existe qu'un seul utilisateur
humain sur la machine. Il est possible de désactiver l'affichage de cette
liste avec une propriété dconf, cf GNOME - Disable the user list, et
alors l'écran d'accueil demande la saisie de l'identifiant de l'utilisateur.
En mode PKI (gdm-smartcard), l'écran d'accueil GDM propose directement
la saisie de l'identifiant de l'utilisateur, il ne propose pas la liste
des utilisateurs existants, et la propriété disable-user-list n'est
pas prise en compte.
Les modules PAM qui exploitent PKCS#11 savent extraire l'identifiant de l'utilisateur à partir des données présente dans un certificat d'authentification, une fois le mapper configuré. Cette information est utilisée principalement pour déterminer où est le compte de l'utilisateur sur le disque, elle n'est pas forcément utilisée pour identifier l'utilisateur lui-même.
Pour pam_pkcs11, il est possible de configurer le module pour qu'il
identifie directement l'utilisateur depuis le certificat, sans aucune
saisie clavier, cf le "alternate way of working" décrit dans le README.
(voir Notes_pkcs11.md pour plus de détails).
Néanmoins, GDM est incapable d'exploiter cette information de cette manière, il ne sait pas sélectionner l'utilisateur à partir d'un certificat, il affiche systématiquement le champ de saisie de l'identifiant en mode smartcard.
Configuration dconf
Pour désactiver le login avec smartcard, je me suis inspiré de la
documentation GNOME - Disallow login using a fingerprint propose de
créer un profil user pour dconf, hélas, ça ne fonctionne pas !
En revanche, avec un profil gdm comme dans GNOME - Add a greeter logo to
the login screen, c'est bon, on observe le comportement attendu, lorsque
le dongle PKI est présent dans le port USB, c'est bien un login/password
qui est demandé par GDM.
Documentation pas à jour ?
Important: après avoir modifié une valeur dans /etc/dconf/db/gdm.d/*,
il faut faire prendre en compte cette modification par dconf, puis
redémarrer le service gdm3:
$ sudo dconf update
$ sudo restart gdm3.service
Les modes de fonctionnement choisis
Pour l'instant, deux modes de fonctionnement:
gdm-password+pam_sss+common-authgdm-smartcard+pam_pkcs11
Dans le premier mode, le smartcard est explicitement désactivé dans
dconf, GDM ne reconnait pas le token PKCS#11 à la connexion, il
ne demande pas le username, c'est la connexion classique à laquelle
l'utilisateur est habitué, pas de régression. Le module pam_sss
est configuré pour authentifier via Kerberos, et le common-auth
permet les solutions de secours (pam_unix et pam_ccreds).
Dans le deuxième mode, le token PKCS#11 est utilisé à la connexion
si présent, sinon authentification classique avec mot de passe local
(pam_unix). Dans un cas comme dans l'autre, pas d'authentification
Kerberos, donc pas de TGT à la connexion.
A l'étude, un troisième mode de fonctionnement avec PKCS#11 dans SSSD.