Files
orange-yourdev-login/Notes.md
Michel Decima 6c7a4fd683 feat: add pam-pkcs11 configuration
Recommends sssd, sssd-tools, libpam-sss
Add SSSD configuration (sssd.conf)
Configure certificates for SSSD (postinst)
Restart SSSD service (postinst)
2021-10-13 09:08:02 +02:00

6.6 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 sudo lorsque 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 kinit manuel dans un terminal ou bien utiliser l'applet krb5-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-krb5 dans 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:

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_krb5 et pam_pkcs11

Voir Notes_pkcs11.md pour la configuration pam_pkcs11.

Voir Notes_sssd.md pour la configuration pam_sss.