Résumé

  • Dans la comparaison publiée par Jerry Saltzer en 1974, les liens de CTSS compliquaient le retrait d’un accès et l’inventaire des ayants droit ; sous Multics, le lien ne servait plus qu’à nommer indirectement une ressource.
  • La liste d’accès attachée à la ressource rendait l’autorité plus lisible, sans pour autant reprendre les données déjà copiées ni garantir que toute décision mémorisée avait reçu la révocation.

Un propriétaire retire un droit. Pourtant, l’entrée qui a servi au partage demeure dans le répertoire de l’emprunteur. Qui doit intervenir ? Où faut-il chercher pour savoir si d’autres entrées équivalentes existent encore ? Dans un petit système, la réponse peut tenir dans une liste. Dans un service partagé par des milliers de personnes, elle devient une question d’architecture.

C’est par ce détour que l’étude de Jerry Saltzer sur la protection dans Multics reste instructive. Il compare le système à CTSS, où un utilisateur pouvait placer dans son propre répertoire un lien vers le fichier d’autrui. Ce lien nommait l’original et comportait généralement des restrictions supplémentaires sur les usages permis. Le dispositif facilitait le partage, mais dispersait aussi une part de la décision chez les emprunteurs.

Saltzer en tire trois difficultés. Retirer un accès imposait de modifier le répertoire de l’emprunteur. Une même personne pouvait disposer de droits différents sur un même fichier selon le lien choisi. Enfin, établir la liste des personnes autorisées obligeait à parcourir tous les répertoires, au prix d’un audit coûteux et potentiellement indiscret.

Un nom sans pouvoir propre

Multics a conservé le lien, mais lui a retiré cette fonction d’autorisation. Le lien restait utile pour atteindre une ressource par un autre nom ; il n’était qu’une adresse indirecte. La permission se trouvait dans la liste de contrôle d’accès associée au segment visé.

Le segment occupait une place particulière dans Multics. Il formait une unité nommée du stockage, une unité mappée dans la mémoire virtuelle d’un processus et une unité de protection. Le processus possédait un identifiant de principal que le système comparait aux entrées de la liste du segment. L’entrée applicable précisait aussi le type d’opération autorisé : lecture, écriture ou exécution pour un segment ; d’autres verbes pour une file de messages ou un répertoire.

Cette organisation évitait de demander au chemin de répondre à deux questions. Le lien disait « quelle ressource ? ». La liste disait « ce principal peut-il effectuer cette opération ? ». Deux chemins menant au même segment ne devaient pas créer, par leur seule existence, deux régimes d’autorité.

La révocation devenait alors une modification du registre placé auprès de la ressource, non une chasse à toutes les portes qui la nommaient. L’audit pouvait partir de la ressource et de sa liste. Le gain n’était pas une sécurité automatique : il était la possibilité de désigner le lieu où la décision devait être expliquée.

La simplicité contre l’héritage magique

Le texte de Saltzer ne décrit pas une progression sans hésitation. Une ancienne version de Multics utilisait la liste initiale d’un répertoire comme annexe commune aux listes de toutes les ressources qu’il contenait. Modifier l’annexe paraissait élégant : un changement au niveau du répertoire pouvait se répercuter partout. Mais l’ordre et la combinaison des entrées produisaient des effets différents selon les ressources. Les utilisateurs ne parvenaient plus à prévoir clairement le résultat.

Les concepteurs ont préféré copier la liste initiale lors de la création d’une ressource. La solution était moins dynamique, puisque le changement du défaut ne réécrivait pas les ressources existantes. En échange, chaque ressource présentait un état plus autonome. Saltzer décrit cette décision comme un arbitrage entre souplesse d’expression, facilité de compréhension et économie de réalisation.

Le même arbitrage explique la sobriété du lien. Autoriser chaque chemin à porter ses propres conditions offre de la finesse. Cette finesse fabrique aussi des états concurrents, des exceptions oubliées et des retraits difficiles à prouver. Une politique plus riche n’est pas nécessairement une politique mieux gouvernée si personne ne peut en anticiper les conséquences.

Vérifier l’autorité, puis suivre sa mémoire

Le principe de médiation complète, formulé plus tard dans le tutoriel signé par Saltzer et Michael D. Schroeder, exige que chaque accès soit soumis à l’autorité. L’étude de 1974 ajoute un détail essentiel : un système qui fonctionne en continu mémorise parfois une décision pour un usage futur. Toute modification de l’autorité doit donc pouvoir atteindre ces mémoires locales.

Une vérification effectuée à l’ouverture traditionnelle d’un fichier ou lors du mappage d’un segment ne signifie pas qu’une liste est relue pour chaque octet. Si une session, un descripteur, un mappage ou un cache conserve l’ancienne réponse, modifier la liste centrale ne suffit pas à démontrer la fin de l’accès. Il faut connaître la durée de la décision et le mécanisme qui la renouvelle ou l’invalide.

L’enregistrement utile relie au minimum le principal, la ressource effectivement résolue, l’opération, la version de règle et l’instant de décision. Le retrait possède ensuite son propre cycle : modification acceptée, mémoires dépendantes invalidées, anciennes sessions expirées, nouvel essai refusé. Une interface qui n’affiche que « permission supprimée » masque l’étape la plus difficile.

Ce que le retrait ne peut reprendre

La séparation entre nom et autorité améliore le retrait, mais ne remonte pas le temps. Saltzer précise qu’un lecteur autorisé peut produire une copie. Supprimer ensuite son accès au segment source ne détruit pas ce qu’il a déjà emporté. Le contrôle après divulgation restait un problème ouvert.

Multics lui-même n’est pas présenté comme un modèle achevé. Le papier répertorie des mécanismes incomplets et une zone très protégée encore trop vaste. Cette franchise fixe la bonne portée de la leçon. Une limite claire rend le composant de confiance visible ; elle ne prouve ni sa correction ni sa petitesse.

Aujourd’hui encore, un lien partagé, un alias ou un identifiant de ressource peut être confondu avec un droit. La distinction de Saltzer oblige à tenir quatre registres : les noms qui conduisent à la ressource, les autorisations en vigueur, les usages effectivement observés et la propagation des retraits. Le lien peut survivre. La permission, elle, doit toujours pouvoir être interrogée ailleurs.

Sources