Recommends libpam-pkcs11 package. Add configuration for Safenet module (pam_pkcs11.conf) Add UID mapper generator (pkcs11_generate_uids) Configure certificates for pam_pkcs11 from postinst.
6.5 KiB
Motivation
Depuis Hirsute, lorsque le dongle PKI est présent avant l'ouverture
de session, GDM ne propose plus directement la liste des utilisateurs
humains présents sur la machine, mais demande la saisie d'un identifiant,
et ensuite un PIN au lieu du mot de passe, puis il échoue dans l'ouverture
de session. C'est particulièrement pénible quand on démarre la machine
en utilisant le dongle PKI pour déverrouiller le volume LUKS, il faut
ensuite l'enlever au bon moment avant le démarrage de GDM.
Il faudrait soit empêcher la détection du dongle par GMD et forcer
le login à l'ancienne avec le mot de passe, soit configurer proprement
PKCS#11 dans GDM pour permettre un login avec la PKI.
Le module pam_krb5 utilisé dans le paquet orange-yourdev-kerberos
fait le job, il permet l'authentification sur le serveur Kerberos et
l'obtention d'un TGT, mais il présente plusieurs inconvénients:
- pas de limitation de la durée de connexion au serveur Kerberos,
donc des ralentissements pénibles a l'ouverture de session ou
lors d'un
sudolorsque la machine n'est pas connectée au réseau interne. - pas de mécanisme "delayed kinit", donc si le TGT n'a pas été
obtenu immédiatement lors de l'ouverture de session, il faut ensuite
faire un
kinitmanuel dans un terminal ou bien utiliser l'appletkrb5-auth-dialog, c'est particulièrement pénible depuis l'arrivée du 802.1x sur les connexion ethernet ou lorsqu'on utilise le wifi interne. - pérennité du paquet
libpam-krb5dans les distributions ?
Il serait intéressant de passer à SSSD, qui permet de définir un timeout de connexion, sait gérer un cache local d'authentification et la reconnexion au serveur Kerberos. Et puis si un jour on veut joindre le domaine AD, on aura déja l'infrastructure en place sur le poste client.
Les règles de sécurité imposent l'affichage d'une bannière "légale" sur l'écran de connexion avant l'ouverture de la session.
Premières impressions
Il existe un paramétrage dconf pour activer/desactiver le login par smartcard dans GDM, ce qui permet de résourdre le problème sur Hirsute quand le dongle PKI est inséré, tant que la configuration PKCS#11 n'est pas en place.
Voir les liens:
- GNOME Configuration - Simple Greeter Configuration
- GNOME - Add a greeter logo to the login screen
- GNOME - Display a text banner on the login screen
- GNOME - Disallow login using a fingerprint
La documentation ne mentionne pas explicitement la gestion des smartcard, mais on peut s'inspirer du paramétrage "fingerprint" avec la clé "enable-smartcard-authentication".
Le module historique pam_pkcs11 sait gérer l'authentification par dongle
PKI une fois configuré, mais pam_sss sait le faire aussi, de manière
indépendante, ce qui explique les alternatives "sssd-exclusive" et
"pkcs11-exclusive" pour gdm-smartcard.
Avec pam_pkcs11, il faut configurer le mapping entre le certificat et le
compte utilisateur local, il existe plusieurs méthodes (cn, fingerprint,
uid) qui sont faciles à mettre en oeuvre. Ces méthodes fonctionnent toutes
en mode debug, mais dans GDM la recherche du compte échoue systématiquement
et il est nécessaire de saisir explicitement l'identifiant de l'utilisateur.
Ca ne devrait pas être nécessaire, est-ce un bug dans GDM ou un problème
de configuration ?
Voir les liens:
Avec pam_sss, la configuration Kerberos n'est pas difficile, elle peut
réutiliser en partie la configuration /etc/krb5.conf. Pour obtenir les
informations relatives au compte, il n'est pas nécessaire d'utiliser LDAP,
ça fonctionne très bien avec un compte local. Bref c'est presque pareil
qu'avec pam_krb5, avec en plus un timeout de connexion au serveur (et
d'autres avantages).
Pour la configuration PKCS#11 dans SSSD, c'est plus difficile, il faut
d'abord définir le module (.so) à utiliser et la documentation n'est pas
claire, et ensuite définir le mapping certificat/utilisateur avec une
syntaxe qui relève de la cryptographie, cf sss-certmap(5).
Voir les liens:
Pour GDM, on a plusieurs modes de fonctionnement que l'on va choisir avec
update-alternatives --config gdm-smartcard. Les trois possibilités sont:
- gdm-smartcard-sssd-exclusive (le défaut)
- gdm-smartcard-pkcs11-exclusive
- gdm-smartcard-sssd-or-password
Seule la dernière fait l'inclusion de /etc/pam.d/common-auth, fichier
qui est généré par pam-auth-update. Donc dans les deux premiers mode,
le paramétrage standard de PAM est ignoré pour le login graphique,
il ne sera utilise que pour le login console ou SSH.
(il va être nécessaire de bien décortiquer et comprendre ces alternatives
gdm-smartcard-*, et plus généralement se documenter sur le fonctionnement
de PAM...)
Il devrait être possible d'obtenir un TGT Kerberos à partir du dongle PKI dans SSSD, mais cela n'a pas l'air évident au premier abord.
Le plan
Créer un nouveau paquet orange-yourdev-login qui reprend les
fonctionnalités de orange-yourdev-kerberos et le remplace, parce que
c'est plus sûr que modifier le paquet existant, ça risque de casser le
login, et ça serait une catastrophe pour les utilisateurs.
On introduit les fonctionnalités pas à pas:
- désactivation du smartcard dans GDM
- configuration PKCS#11 avec
pam_pkcs11, utilisation optionnelle - ajout de SSSD en remplacement de
pam_krb5, mot de passe seulement - configuration PKCS#11 avec
pam_sss - suppression de
pam_krb5etpam_pkcs11
Voir Notes_pkcs11.md pour la configuration pam_pkcs11.