Résumé

  • RFC 2307 proposait de représenter dans LDAP les comptes et groupes Unix ainsi que des ressources réseau. Sa classe posixAccount comprenait uidNumber, l’entier utilisé par les fonctions de recherche du système.
  • La section sécurité de RFC 2307 décrit la conséquence d’un droit d’écriture mal attribué : un utilisateur pouvant changer uidNumber pouvait rendre son compte équivalent à celui du superutilisateur.

La recherche commence par un entier

Un processus Unix ne demande pas à un annuaire d’expliquer qui est quelqu’un. Il remet un nombre à la bibliothèque C et attend une fiche de compte en retour. RFC 2307 prend getpwuid() pour exemple : la fonction associe un identifiant utilisateur à un nom de connexion. Dans la forme LDAP proposée, la recherche vise une entrée posixAccount dont uidNumber correspond au nombre reçu.

Le champ ressemble à un détail de classement. Le logiciel, lui, le traite comme une identité.

Avant LDAP, les réseaux Unix pouvaient partager les données de comptes et de machines grâce au Network Information Service (NIS). Le guide d’administration de Sun décrit les cartes NIS comme des tables à deux colonnes : une clé et la valeur qui lui correspond. Le serveur maître d’un domaine conserve les cartes ; des serveurs esclaves en gardent des copies ; les clients interrogent l’un ou l’autre. passwd.byname retrouve un compte par nom, tandis que passwd.byuid prend l’identifiant utilisateur comme clé. Les administrateurs construisent les cartes à partir de fichiers d’entrée sur le maître, puis propagent les résultats aux esclaves.

Une modification de fichier devenait ainsi une décision de réseau. On change le fichier source, on reconstruit la carte, et les clients du domaine peuvent recevoir la nouvelle réponse. Le code de recherche ne vote pas sur la pertinence de l’identifiant : il consomme la valeur qui lui arrive.

Le manuel SunOS de 1999 raconte au passage un détour de marque : NIS s’appelait auparavant Sun Yellow Pages, mais ses fonctions sont restées identiques après le changement de nom. L’étiquette a changé ; les cartes de comptes n’ont pas perdu leur poids.

LDAP changeait le répertoire, pas les permissions

La spécification LDAPv3 de 1997 proposait un accès aux annuaires X.500 avec moins de ressources que le protocole DAP complet. Trois mois plus tard, RFC 2307, intitulé An Approach for Using LDAP as a Network Information Service, proposait des classes et attributs LDAP pour les données Unix et TCP/IP.

La liste dépassait largement les noms d’hôtes : comptes et groupes, services et numéros de protocole, identifiants RPC, paramètres de démarrage, adresses réseau et groupes NIS. Une entrée posixAccount pouvait porter un nom de connexion, un nom d’affichage, uidNumber, gidNumber, un répertoire personnel et un interpréteur de commandes. RFC 2307 fournit même l’exemple d’une ligne de type fichier de mots de passe représentée sous forme d’attributs.

L’intégration avait une logique simple. Les programmes Unix demandaient déjà les comptes à la bibliothèque C ; le système pouvait orienter cette recherche vers un annuaire réseau plutôt que vers un fichier local. La section consacrée à l’implémentation décrit un serveur NIS adossé à LDAP, du code de référence pour la bibliothèque C et des scripts convertissant des fichiers comme /etc/passwd et /etc/hosts en entrées d’annuaire.

Le document n’ordonnait pas à tous les sites Unix de migrer. Publié comme Experimental, il proposait une méthode de service d’annuaire pour les organisations. RFC 2307 indiquait qu’un mécanisme avait déjà été implémenté avec un certain succès, sans compter les installations ni mesurer son adoption.

Le nombre faisait frontière

La section sécurité de RFC 2307 ne cache pas le pouvoir d’un attribut d’annuaire. Elle dit que seuls les administrateurs devraient modifier les entrées du schéma liées au système d’exploitation. Puis elle en donne la raison : si un utilisateur pouvait changer son uidNumber, il pouvait compromettre la sécurité en rendant son compte équivalent à celui du superutilisateur.

RFC 2307 formule un risque conditionnel et désigne le point de contrôle : le logiciel Unix associe le nombre à un compte ; un annuaire peut publier cette correspondance auprès de nombreux clients ; celui qui contrôle les écritures peut changer l’identité qu’ils voient. Le logiciel Unix rapproche le nombre d’un compte ; un annuaire peut publier cette correspondance auprès de nombreux clients ; celui qui contrôle les écritures peut changer l’identité qu’ils voient. Le schéma décrit la syntaxe. La règle d’accès décide qui peut lui donner effet.

La même section repère une seconde collision entre recherche et privilège. Rendre accessibles aux utilisateurs non privilégiés des mots de passe chiffrés avec des fonctions répandues comme crypt() peut faciliter les attaques par dictionnaire et force brute. RFC 2307 présente cette exposition comme une compatibilité avec les systèmes Unix existants et recommande un service d’authentification fort lorsque la sécurité l’exige. Un annuaire partagé simplifie les recherches, mais peut aussi ouvrir des données sensibles à davantage de clients.

Les sources établissent une conception et ses risques déclarés, pas l’ampleur de son déploiement LDAP. La note d’implémentation de RFC 2307 atteste une implémentation ; aucun document de ce dossier ne mesure la diffusion de ce schéma parmi les systèmes Unix.

La transformation importante n’était pas l’ajout d’un schéma à une base. C’était l’accord d’un système d’exploitation pour laisser une réponse réseau trancher une question locale. uidNumber pouvait rester une colonne ; c’est le processus qui l’interprétait qui lui donnait son poids. Passer de /etc/passwd à NIS ou LDAP déplaçait aussi le point de contrôle : l’administrateur devait savoir quelle source faisait foi, quelles copies détenaient la carte la plus récente et qui pouvait modifier le champ d’identité.

Sources