Qu'est-ce qu'une capabilité en fin de compte ?

Qu'est - ce qu'une capabilité en fin de compte ?
Jonathan Shapiro
Copyrights 1999, license GNU

Page en cours de formatage - à partir d'une traduction automatique pour mettre des termes et des notes en français ...

attention je traduis "capability" par "capabilité" par souci terminologique. Le sens du mot capabilité en français comme en anglais me paraissant plus proche que celui de "capacité" par lequel il peut aussi être traduit. AMHA ce terme est commun à la technologie logicielles et à la technosophie.

__________________________

Récemment, un ami non programmeur a fait remarquer qu'il n'y avait pas d'explication simple des capabilités disponibles sur le Web. Moins d'une semaine plus tard, un autre ami - celui-ci, un développeur de système d'exploitation senior pour une grande société de logiciels UNIX - m'a dit qu'il ne comprenait vraiment pas ce sur quoi je travaillais (capabilités). Si ni le lecteur profane ni les experts ne comprennent ce que sont ces choses, une description introductive est absolument nécessaire, alors je me suis mis à en écrire une. J'ai rapidement découvert que ce n'était pas facile. Les capabilités elles-mêmes sont très simples, mais elles bouleversent tout ce que les gens `` savent sur la sécurité. Beaucoup de gens les regardent et disent `` c'est trop simple pour éventuellement fonctionner .

Cet essai est une introduction de base: aux capabilités et aux systèmes basés sur les capabilités. Plutôt que d'essayer de donner une discussion exhaustive, j'ai pris quelques libertés éditoriales dans un souci de clarté:

Cet essai est informel 

Mon objectif ici est de faire passer le cœur d'une idée plutôt que de donner chaque détail avec précision. Il y a un certain nombre d'endroits où aller pour obtenir des informations plus détaillées.

Cet essai est partisan 

J'ai choisi de parler d'un style particulier de système de capabilité. Je pense que c'est le meilleur, mais d'autres valent la peine d'être examinés si vous avez envie de le faire. Si vous arrivez au point de comparer les systèmes de capabilités, vous avez dépassé le point de demander ce qu'ils sont et vous demandez maintenant comment ils devraient être mis en œuvre. Ceci, cependant, est un sujet pour un essai différent.

Cet essai vous expliquera 

ce que recouvre le terme contrôle d'accès , ce qu'est une capabilité, et fournira quelques exemples de la manière dont les capabilités peuvent être utilisées pour fournir un accès flexible aux objets sans renoncer à la sécurité. Je vais décrire certains problèmes que les mécanismes de contrôle d'accès actuellement populaires ne peuvent pas gérer. Je vais parler du problème de la révocation de l' accès et de la façon dont cela est résolu. Enfin, je donnerai ma propre opinion sur la manière dont les capabilités ont été rejetées par les informaticiens traditionnels.

Bien que cet essai utilise UNIX comme système d'exemple, les problèmes identifiés avec UNIX existent également dans VMS, Windows / NT et Windows95.

Si vous trouvez cette note utile, ou si vous avez des suggestions d'amélioration, envoyez-moi un mail à shap@eros-os.org .

1. Le problème: le contrôle d'accès

Le problème fondamental de la sécurité informatique est de contrôler les objets auxquels un programme donné peut accéder et de quelle manière. Les objets sont des éléments tels que des fichiers, des cartes son, d'autres programmes, le réseau, votre modem, etc. L'accès désigne le type d'opérations qui peuvent être effectuées sur ces objets. Les exemples incluent la lecture d'un fichier, l'écriture dans un fichier, la création ou la suppression d'objets, la communication avec un autre programme, etc.

Lorsque nous parlons de `` contrôle de l'accès , nous parlons en réalité de quatre types de choses:

Empêcher l' accès: vous voulez vous assurer qu'une personne ne peut pas en endommager une autre ou jeter un coup d'œil aux informations privées d'une autre personne. Je ne devrais pas pouvoir lire votre dossier médical, par exemple. Vous ne devriez pas pouvoir supprimer mon travail. C'est ce que la plupart des gens veulent dire lorsqu'ils parlent de sécurité informatique.

Limiter l' accès. Vous voulez vous assurer qu'un programme ou un utilisateur ne fait pas plus que ce que vous voulez. Par exemple, vous souhaiterez peut-être exécuter un programme hors du Web mais empêcher le programme de lire ou d’écrire des fichiers afin qu’il ne puisse pas planter un virus informatique ou donner votre annuaire privé. Ce problème a attiré plus d'attention ces derniers temps avec tout le battage médiatique autour de Java.

Accorder l' accès. Vous souhaiterez peut-être autoriser deux personnes à travailler ensemble sur un document ou accorder l'accès à un fichier particulier à quelqu'un d'autre afin que vous puissiez leur déléguer un travail. Notez cependant que vous souhaitez probablement le faire de manière sélective . Ce n'est pas parce que nous travaillons ensemble sur un plan d'affaires que je devrais lire vos dossiers médicaux. D'un point de vue pratique, c'est tout aussi important que les deux premiers, mais les responsables de la sécurité n'ont pas tendance à y penser beaucoup.

Révocation de l' accès. Après avoir autorisé l'accès à un objet, vous devrez peut-être ultérieurement reprendre cet accès lorsque la personne n'est plus autorisée à consulter un document particulier.

Le contrôle d'accès consiste à déterminer à quoi un programme peut accéder, pas à ce à quoi une personne peut accéder. Dans les ordinateurs, les gens n'accèdent pas aux objets; les programmes le font. Cette distinction a une importance pratique pour plusieurs raisons:

La même personne peut s'exécuter avec différentes identités d'utilisateur (connexions). J'ai un compte en tant qu'administrateur système différent de celui que j'utilise pour les activités quotidiennes.

Le même programme peut être exécuté par différents utilisateurs à des moments différents avec des autorités différentes. Ce n'est pas parce que vous et moi exécutons le même traitement de texte que nous devrions tous les deux pouvoir accéder aux mêmes fichiers.

Les programmes spéciaux doivent parfois avoir plus d'autorité que l'utilisateur. Le programme de mots de passe, par exemple, a le droit de modifier le fichier de mots de passe même si l'utilisateur typique ne l'est pas. Le programme de mot de passe prend soin de ne le faire que d'une manière appropriée.

Les gens ne savent pas toujours quels programmes ils exécutent. Si vous lisez cet essai dans un navigateur compatible Java, vous verrez une image du feu en mouvement vers la droite. Il s'agit d'une démo Java écrite par Lars Nicolai Løvdal de Norvège; Je n'ai aucune idée de qui il est ou de ce que fait réellement ce programme de démonstration. Lorsque vous avez ouvert ce document, vous n'aviez pas l'intention d'exécuter ce programme, mais il est là, fuyant. De la même manière, des applications comme Microsoft Word sont constituées de nombreux composants provenant de nombreux fournisseurs. Puisque vous ne savez pas qui a fourni votre logiciel, il est difficile de savoir si vous pouvez leur faire confiance.

Après avoir préparé le terrain, nous pouvons maintenant nous tourner vers ce que sont les capabilités et comment le contrôle d'accès est accompli en les utilisant.

2. Qu'est-ce qu'une capabilité

Le terme capabilité a été introduit par Dennis et Van Horn en 1966 dans un article intitulé Programming Semantics for Multiprogrammed Computations . L'idée de base est la suivante: supposons que nous concevons un système informatique de sorte que pour accéder à un objet, un programme doit avoir un jeton spécial. Ce jeton désigne un objet et donne au programme l'autorisation d'effectuer un ensemble spécifique d'actions (telles que la lecture ou l'écriture) sur cet objet . Un tel jeton est appelé capabilité .

Une capabilité ressemble beaucoup aux clés de votre trousseau de clés. À titre d'exemple, considérez votre clé de voiture. Il fonctionne sur une voiture spécifique (il désigne un objet particulier), et toute personne détenant la clé peut effectuer certaines actions (verrouillage ou déverrouillage de la voiture, démarrage de la voiture, ouverture de la boîte à gants). Vous pouvez me remettre votre clé de voiture, après quoi je peux ouvrir, verrouiller ou démarrer la voiture, mais uniquement sur votre voiture. Tenir votre clé de voiture ne me permettra pas de tester la Lamborghini de mon voisin (ce qui est tout aussi bien - je l'enroulerais sans aucun doute autour d'un arbre quelque part). Notez que la clé de la voiture ne sait pas que c'est moi qui démarre la voiture; il suffit que je possède la clé. De la même manière, les capabilités ne se soucient pas de qui les utilise .

Les clés de voiture se déclinent parfois en plusieurs variantes. Les deux clés courantes sont la clé de voiturier (démarre, verrouille et déverrouille la voiture, mais pas la boîte à gants) ou la clé de porte (verrouille / déverrouille la voiture, mais ne la démarre pas). De cette manière exactement, deux capabilités peuvent désigner le même objet (comme la voiture) mais autoriser différents ensembles d'actions . Un programme peut détenir une capabilité de lecture seule sur un fichier tandis qu'un autre détient une capabilité de lecture-écriture sur le même fichier.

Comme pour les clés, vous pouvez me donner une capabilité à une boîte pleine d'autres capabilités.

Les capabilités peuvent être déléguées . Si vous me donnez votre clé de voiture, vous me faites confiance pour ne pas la remettre à quelqu'un d'autre. Si vous ne voulez pas me faire confiance, vous ne devriez pas me donner la clé.

Les capabilités peuvent être copiées . Si vous me donnez votre clé de voiture, rien ne m'empêche de me rendre chez mon concessionnaire automobile local et de faire fabriquer une clé en double. En pratique, ce n'est pas vraiment un problème, car vous ne m'auriez pas donné la clé si vous ne me faisiez pas confiance. S'il s'agit de mesures désespérées, vous pouvez changer les serrures de la voiture, rendant toutes les clés inutiles. Cela peut également être fait avec des capabilités; c'est ce qu'on appelle la séparation d' un objet, ce qui a pour effet d' annuler toutes les capabilités. Une capabilité annulée ne confère aucune autorité pour faire quoi que ce soit.

En fait, il n'y a que quelques façons dont les capabilités et les clés ordinaires sont différentes. Les différences importantes sont:

Les capabilités sont plus faciles à copier. Aucun serrurier n'est requis. Plutôt que de remettre une capabilité originale, l'action la plus courante consiste à en remettre une copie.

Les capabilités sont plus difficiles à contourner. Je peux casser ta vitre et filer ta voiture. Il est beaucoup plus difficile d'entrer dans un système de capabilités.

Les capabilités peuvent avoir plus de variantes. Créer un nouveau type de capabilité (par exemple: celui qui me permet de me renseigner sur la taille d'un fichier, mais pas de le lire) est simplement une question d'ajouter un peu de logiciel.

Points clés: Les capabilités sont simples et familières. Vous les utilisez tous les jours et ils ne vous surprennent pas très souvent. Si vous pensez aux clés ordinaires et aux types de contrôles d'accès qu'elles fournissent, vous ne vous tromperez pas beaucoup.

Pour être utiles, les capabilités doivent être infalsifiables. Si vous pouviez simplement évoquer la clé de la voiture de votre choix, elles ne fourniraient pas beaucoup de protection. Les capabilités de protection contre la falsification peuvent être gérées dans le matériel ou dans le logiciel système. L'approche logicielle est plus pratique car elle peut fonctionner sur un PC ordinaire. EROS , qui est actuellement le système de capabilité le plus rapide existant, le fait dans le logiciel système, et les données suggèrent qu'il n'y aurait aucun avantage réel à le faire dans le matériel.

3. Systèmes informatiques basés sur les capabilités

Dans un système informatique basé sur les capabilités, tous les accès aux objets se font via des capabilités, et les capabilités fournissent le seul moyen d'accéder aux objets. Dans un tel système, chaque programme possède un ensemble de capabilités. Si le programme A possède la capabilité de parler au programme B, alors les deux programmes peuvent s'accorder des capabilités l'un à l'autre. Dans la plupart des systèmes de capabilités, un programme peut contenir un nombre infini de capabilités. De tels systèmes ont tendance à être lents. Une meilleure conception permet à chaque programme de contenir un nombre fixe (et petit - comme 16 ou 32) de capabilités, et fournit un moyen de stocker des capabilités supplémentaires si elles sont nécessaires. La seule façon d'obtenir des capabilités est de vous les accorder à la suite d'une communication.

Détenir un grand nombre de capabilités est généralement insensé. Le but est de rendre l'ensemble des capabilités détenues par chaque programme aussi spécifique et aussi petit que possible, car un programme ne peut pas abuser de l'autorité qu'il n'a pas. C'est ce qu'on appelle le principe du moindre privilège .

Dans ce type de système, un programme qui souhaite effectuer une opération sur un objet doit détenir une capabilité sur cet objet. Pour exécuter l'action, il appelle la capabilité et nomme l'action à effectuer. Dans le système d'exploitation UNIX®, par exemple, l'appel système d'appel read(fd, buf, sz) système peut être considéré comme effectuant l' read opération sur le fichier nommé par fd (la capabilité), en passant les arguments buf et sz. Outre le fait que les descripteurs de fichier UNIX contiennent des informations associées sur le décalage de fichier actuel, un descripteur de fichier UNIX est essentiellement une capabilité.

Écrire les choses

Le principal problème avec les capabilités est de trouver un moyen de les enregistrer sur le disque afin que vous puissiez les récupérer. C'est l'une des principales raisons pour lesquelles peu de systèmes de capabilités ont été construits et la principale raison pour laquelle la plupart des systèmes de capabilités actuels tombent en panne à la limite du système de fichiers.

Supposons pendant une minute que votre programme avait une capabilité qui lui permettait de créer un fichier et d'y écrire des choses. Supposons qu'il le fasse, et que toutes les informations dont vous avez besoin ont maintenant été écrites. Ma chienne serviable, Sheena, vient maintenant et coupe la prise de votre ordinateur du mur. Nous démarrons le système et nous devons maintenant répondre à un problème de poule et d'œuf:

Pour accéder au fichier, vous devez d'abord avoir une capabilité sur le système de fichiers. D'où les premiers programmes tirent-ils leurs capabilités?

De quelle autorité les détiennent-ils?

Ces problèmes ont fondamentalement déconcerté les concepteurs de systèmes capacitaires jusqu'au début des années 1970.

Solution conventionnelle: listes de contrôle d'accès

La solution habituelle a été d'avoir une sorte de système de fichiers, d'accorder à chaque programme le droit d'utiliser le système de fichiers et d'utiliser une sorte de système basé sur l'identité de l'utilisateur pour décider quels programmes peuvent ouvrir quels fichiers. Si un programme est en cours d'exécution au nom de Natasha (mon autre chien), il peut ouvrir n'importe quel fichier créé par Natasha. Un tel système est appelé système de liste de contrôle d'accès (ACL). Chaque objet est associé à une liste d'utilisateurs et des actions que chaque utilisateur est autorisé à effectuer. Si l'utilisateur figure sur la liste de contrôle d'accès, les programmes fonctionnant pour le compte de cet utilisateur peuvent obtenir une capabilité pour cet objet. Une fois qu'ils en ont la capabilité, ils peuvent manipuler l'objet lui-même. C'est le but de l' open appel système UNIX .

Prenez une minute pour revenir en arrière et examiner les quatre choses qu'un mécanisme de contrôle d'accès était censé accomplir. Les systèmes ACL peuvent empêcher et révoquer l' accès, mais ils ne peuvent ni limiter l' accès ni accorder l' accès. Tous les programmes exécutés pour le compte de Natasha - même ce programme d'enfer qui fait rage écrit par un inconnu en Norvège - peuvent accéder à n'importe lequel des objets de Natasha. Dans les systèmes ACL actuels, il n'y a aucun moyen de sous-définir ces droits. En outre, il n'y a aucun moyen pour Natasha de me déléguer une partie de son autorité (par exemple, l'accès à un seul fichier qu'elle ne possède pas) à moins que Natasha ne possède le ou les objets en question. À moins qu'elle ne possède l'objet, elle ne peut pas modifier la liste de contrôle d'accès.

Une meilleure solution: la persistance universelle

Une meilleure solution est de ne pas avoir de système de fichiers commun et de ne donner à aucun programme l'accès au système de fichiers par défaut. Les systèmes de fichiers sont très utiles, mais la plupart des programmes et sous-systèmes n'ont pas besoin d'y accéder. Un correcteur orthographique qui s'exécute dans le cadre d'un traitement de texte, par exemple, a besoin d'accéder aux fichiers particuliers sur lesquels il travaille, mais n'a pas besoin d'ouvrir d'autres fichiers (et donc pas besoin d'accéder à un système de fichiers).

Si des choses ne sont pas mémorisées en les écrivant dans un fichier, d'autres moyens doivent être trouvés pour les mémoriser. La solution consiste simplement à se souvenir de tout . Toutes les cinq minutes, notez tout ce sur quoi l'ordinateur travaille. Si Sheena débranche la fiche, le système revient simplement à la dernière copie enregistrée. Étant donné que la copie enregistrée comprend tous les programmes en cours d'exécution, il n'est pas nécessaire de déterminer qui a droit à quoi lorsque le système redémarre.

Vous pourriez penser que c'est une approche inefficace. En pratique, il est en fait plus rapide que les systèmes de fichiers et nécessite moins de code.

Bien entendu, l'utilisateur peut s'être éloigné de la machine, il faut donc un moyen pour reprendre son travail. La solution est de donner à chaque utilisateur un programme qui s'exécute en son nom (le système de fenêtres, si vous le souhaitez) à tout moment. Le travail de l'agent de connexion est de vous reconnecter à votre système Windows, où tous vos programmes sont toujours en cours d'exécution.

La persistance universelle est utilisée à la fois par KeyKOS et EROS . Cela fonctionne très bien.

4. Vous ne pouvez pas y arriver à partir d'ici

Les systèmes de contrôle d'accès traditionnels rencontrent des problèmes avec une variété de problèmes importants. Voici quelques exemples de ces problèmes dans les systèmes informatiques actuels, et une explication de la raison pour laquelle ces problèmes n'existent pas dans les systèmes de capabilités.

Programmes privilégiés

Considérez le programme qui change votre mot de passe. Il a besoin de l'autorisation de lire et d'écrire le fichier de mots de passe, mais ne doit pas vous donner cette autorisation. Dans un système ACL, la seule façon de faire cela est d'avoir accès au fichier de mots de passe limité à un utilisateur spécial ( root ou sysadm), et d'avoir des moyens de dire que le programme de mots de passe s'exécute en tant que cet utilisateur. Cela a conduit à des idées telles que le bit setuid (permet à un programme de s'exécuter à la fois en tant que propriétaire [généralement root] et en tant que vous en même temps) ou la table des privilèges système (VMS: répertorie les programmes avec des privilèges spéciaux dans une table à l'échelle du système ).

Ces deux mécanismes ne sont pas sûrs. Donner au programme de mot de passe toute l'autorité de root est tout simplement trop. Dans le mécanisme VMS, le fichier programme lui-même peut être attaqué, laissant une faille de sécurité difficile à trouver. La prochaine fois que le programme sera exécuté, il obéira au nouveau programme, qui peut absolument tout faire.

Peut-être plus important encore, ces programmes ont tendance à avoir des problèmes avec le temps. Au fur et à mesure que les mainteneurs modifient ces programmes sans bien comprendre leurs contraintes, ils deviennent des sources de nouvelles failles de sécurité.

La bonne solution est de donner explicitement au programme l'accès au fichier de mots de passe, et de ne pas laisser le programme de mots de passe traîner dans un système de fichiers où il peut être écrasé. Dans un système de capabilités, vous donnez simplement au programme une capabilité à la base de données de mots de passe et le laissez s'exécuter pour toujours. Vous donnez ensuite une capabilité qui permet aux gens d'exécuter le programme de mot de passe mais ne les laisse pas lire ou modifier ce programme.

Restriction d'accès

Supposons que vous ayez un programme qui gère vos données financières. Vous ne voulez pas vraiment qu'il envoie ces informations à l'IRS sans votre permission, mais votre ordinateur est connecté au réseau. Dans un système ACL, puisque vous avez accès au réseau, il en va de même pour le programme. Dans un système de capabilités, vous laissez simplement les capabilités du réseau en dehors lorsque vous installez le programme, garantissant qu'il ne peut pas envoyer de données à ces personnes utiles et amicales de l'IRS.

Java résout ce problème par des restrictions ad hoc. Vous avez peut-être remarqué que les gens continuent de trouver de nouveaux problèmes de sécurité avec Java. C'est parce que les mécanismes de sécurité ad hoc ne fonctionnent pas. Il vaut mieux avoir fait le travail correctement en premier lieu. Les capabilités ont un modèle formel et mathématiquement solide qui peut être (et a été) utilisé pour prouver leur sécurité.

Collaboration

Le plus dur, cependant, concerne la collaboration. Supposons que j'ai un programme secret qui est très précieux. J'ai peur de donner le code binaire, parce que quelqu'un va le décompiler et voler mon programme (oui, cela arrive vraiment). Vous avez des données très secrètes concernant les résultats d'un nouvel essai de drogue. Vous devez exécuter mon programme, mais vous ne souhaitez pas me montrer les données.

Dans un système de capabilités, nous pouvons configurer les choses de sorte que vous puissiez exécuter le programme sans pouvoir voir le code, mais vous êtes en mesure de contrôler l'autorité accordée à mon programme. Puisque vous contrôlez les autorités, vous pouvez vous assurer que mon programme ne me révélera pas vos secrets. Puisque vous ne pouvez pas accéder au code binaire, vous ne pouvez pas voler le programme. La plupart des experts en sécurité informatique pensent que cela est impossible. Dans les systèmes ACL, il vraiment est impossible.

5. Révocation sélective de l'accès

Un problème avec les capabilités est qu'il n'y a aucun moyen de dire «Supprimer tout l'accès de Fred à cet objet». Si Sheena (mon chien) décide de me laisser pour un autre propriétaire, comment puis-je lui retirer sa capabilité de canette de nourriture pour chien? De manière plus réaliste, si votre employé part, comment vous assurer que son accès au classeur est coupé. Plus important encore, supposons que l'utilisateur ne soit pas renvoyé, mais qu'il soit simplement déplacé vers un autre service et qu'il ne devrait plus avoir accès aux documents sensibles de son ancien service?

À première vue, il semble y avoir trois cas différents ici:

Supprimer complètement l'accès d'un utilisateur

Révoquer l' accès actuel d' un utilisateur sans supprimer l'utilisateur, éventuellement conserver l'accès à certains de ses fichiers.

Révoquer l'accès d'un utilisateur à un objet particulier .

En fait, les deux derniers cas sont les mêmes.

Dans les systèmes de capabilité et d'ACL, le premier problème est résolu en supprimant la connexion de l'utilisateur.

Dans les systèmes de capabilité et d'ACL, le deuxième problème peut être résolu en créant une nouvelle connexion pour le même utilisateur et en copiant sélectivement dans le nouveau compte les documents personnels auxquels l'utilisateur doit conserver l'accès. Dans de nombreux cas, c'est la meilleure solution. Dans les systèmes capacitaires, une autre solution est possible: construire un compartiment spécial renforcé par logiciel qui empêche les documents d'être copiés hors du compartiment et ne permet à l'utilisateur d'accéder qu'à ces documents à l'intérieur du compartiment. Ce n'est pas la même chose qu'un groupe d'utilisateurs . Dans l'approche de groupe d'utilisateurs, l'utilisateur peut avoir fait des copies des documents. Les supprimer du groupe évitera des dommages futurs, mais ne fait rien pour contrôler le vol tant que l'utilisateur a un accès légitime.

La révocation de l'accès à un objet particulier est exactement comme le problème du compartiment spécial. Soit vous construisez un compartiment spécial à l'avance, soit il n'y a vraiment aucun bon moyen d'empêcher l'utilisateur de s'enfuir avec les données.

6. Pourquoi le Bad Rap?

Donc, si les capabilités sont tellement meilleures que les ACL, pourquoi n'ont-elles pas été utilisées? Comment se fait-il que tant d'entreprises expédient des systèmes d'exploitation non sécurisés alors que nous savons comment résoudre ces problèmes?

Une partie du problème est historique. Les premiers systèmes de capabilité ont été construits dans du matériel avant que nous ne sachions beaucoup sur l'architecture matérielle et utilisaient des capabilités pour accéder à la mémoire principale. Cela les a rendus terriblement lents et terriblement complexes. Ces systèmes sont un peu moins complexes que les systèmes d'exploitation actuels, mais leur réputation persiste.

Dans les années 1970, un système d'exploitation appelé MULTICS est apparu, et la plupart des pays du monde ont galopé sur la piste UNIX. UNIX est un système extraordinaire, conçu à une époque où la plupart des ordinateurs n'étaient pas connectés au monde extérieur. Dans un monde où tous les autres utilisateurs vous sont connus, la collaboration est plus importante que la sécurité. Les mécanismes de sécurité UNIX sont adéquats pour un environnement collaboratif. Jusqu'à l'avènement d'Internet et de la connectivité courante, seules quelques machines exécutant des applications financières dédiées devaient se soucier sérieusement de la sécurité, et ces machines devaient de toute façon l'implémenter dans l'application.

Dans les années 1980, beaucoup de travail vraiment médiocre a été effectué sur les micro-noyaux (qui sont similaires aux systèmes de capabilités modernes), et une analyse tout aussi mauvaise a conclu que le problème était lié aux micro-noyaux en général plutôt qu'aux défauts d'implémentations particulières. Nous avons maintenant des exemples de micro-noyaux qui sont nettement plus rapides que les systèmes d'exploitation conventionnels, et au moins un exemple de système de capabilité qui l'est.

En fin de compte, au cours des 25 dernières années, un énorme investissement a été investi dans des systèmes non sécurisés, et jusqu'à ce qu'il y ait une raison impérieuse de changer ces systèmes, les personnes qui les soutiennent ne s'en soucieront pas. En fait, les éditeurs de logiciels ont pris des mesures pour s'assurer qu'ils ne sont pas tenus responsables des défauts de leurs logiciels, même lorsqu'ils sont réels, démontrables et incontestables. Jusqu'à ce que cela change, il n'y a aucune raison de sécuriser les systèmes. L'un des arguments avancés contre les systèmes de capabilités est que les capabilités et les listes de contrôle d'accès peuvent être rendues formellement équivalentes (si vous effectuez suffisamment de réparations pour accéder aux listes de contrôle, c'est-à-dire). C'est un argument trompeur, car les gens pensent que cela signifie qu'ils sont pareils. Deux choses peuvent être théoriquement le même sans être pratiquement le même. Je peux imaginer des moyens d'augmenter les listes de contrôle d'accès traditionnelles pour gérer les collaborateurs suspects sur papier, mais les solutions sont à la fois trop draconiennes et trop lentes à utiliser.

Les choses changent lentement. Java est un pas partiel dans la bonne direction, et le PR autour de Java commence à réveiller les utilisateurs à quel point ils sont exposés. Au fil du temps, vous pouvez vous attendre à voir certaines des idées Java intégrées dans les systèmes traditionnels.

En fait, des environnements de compatibilité pour UNIX ont été construits pour s'exécuter en toute sécurité sur les systèmes de capabilités (il convient de noter que vous ne pouvez pas créer de système de capabilités sur un système ACL), il n'est donc pas nécessaire de supprimer le code existant.

7. Conclusions

J'espère que vous savez maintenant ce qu'est une capabilité et que vous pourrez commencer à participer aux discussions à leur sujet. À un moment donné, j'ajouterai ici des liens vers d'autres sources d'informations pour les personnes qui souhaitent en savoir plus.

Copyright 1999 par Jonathan Shapiro. Tous les droits sont réservés. Pour les conditions de redistribution, consultez la licence publique générale GNU