What are capabilities ? (bilingual)

What are capabilities?		Que sont les capacités?

May 7, 2017		07-mai-17

What Are Capabilities?		Quelles sont les capacités?

Contents		Contenu

1 Some preliminary remarks		1 Quelques remarques préliminaires

2 The idea		2 L'idée

3 Getting more precise		3 Obtenir plus de précision

4 Modulation		4 Modulation

5 Attenuation		5 Atténuation

6 Abstraction		6 Abstraction

7 Combination		7 Combinaison

8 Embedded systems		8 Systèmes embarqués

9 Compartmentalized computation		9 Calcul compartimenté

10 Distributed services		10 Services distribués

11 Software engineering practices		11 Pratiques de génie logiciel

12 Conclusion		12 Conclusion

13 Acknowledgements		13 Remerciements

14 3 Comments		14 3 commentaires

Some preliminary remarks[edit]		Quelques remarques préliminaires[ modifier ]

You can skip this initial section, which just sets some context, without loss to the technical substance of the essay that follows, though perhaps at some loss in entertainment value.		Vous pouvez sauter cette section initiale, qui ne fait que définir un certain contexte, sans perdre la substance technique de l'essai qui suit, mais peut-être avec une certaine perte de valeur de divertissement.

At a gathering of some of my coconspirators friends a couple months ago, Alan Karp lamented the lack of a good, basic introduction to capabilities for folks who aren’t already familiar with the paradigm. There’s been a lot written on the topic, but it seems like everything is either really long (though if you’re up for a great nerdy read I recommend Mark Miller’s PhD thesis), or really old (I think the root of the family tree is probably Dennis and Van Horn’s seminal paper from 1966), or embedded in explanations of specific programming languages (such as Marc Stiegler’s excellent E In A Walnut or the capabilities section of the Pony language tutorial) or operating systems (such as KeyKOS or seL4), or descriptions of things that use capabilities (like smart contracts or distributed file storage), or discussions of aspects of capabilities (Norm Hardy has written of ton of useful fragments on his website). But nothing that’s just a good “here, read this” that you can toss at curious people who are technically able but unfamiliar with the ideas. So Alan says, “somebody should write something like that,” while giving me a meaningful stare. Somebody, huh? OK, I can take a hint. I’ll give it a shot. Given my tendency to Explain Things this will probably end up being a lot longer than what Alan wants, but ya gotta start somewhere.		Lors d'un rassemblement de certains de mes amis coconspirateurs il y a quelques mois, Alan Karp a déploré le manque d'une bonne introduction de base aux capacités pour les personnes qui ne sont pas déjà familiarisées avec le paradigme. Il y a eu beaucoup d'écrits sur le sujet, mais il semble que tout soit vraiment long (bien que si vous êtes prêt pour une bonne lecture ringard, je recommande la thèse de doctorat de Mark Miller), ou vraiment vieux (je pense que la racine de l'arbre généalogique) est probablement l'article fondateur de Dennis et Van Horn de 1966), ou intégré dans des explications de langages de programmation spécifiques (comme l'excellent E In A Walnut de Marc Stiegler ou la section des capacités du tutoriel sur le langage Pony) ou des systèmes d'exploitation (tels que KeyKOS ou seL4) , ou des descriptions de choses qui utilisent des capacités (comme les contrats intelligents ou le stockage de fichiers distribué), ou des discussions sur les aspects des capacités (Norm Hardy a écrit une tonne de fragments utiles sur son site Web). Mais rien qui soit juste un bon «ici, lisez ceci» que vous puissiez lancer à des personnes curieuses qui sont techniquement capables mais qui ne connaissent pas les idées. Alors Alan dit: «quelqu'un devrait écrire quelque chose comme ça», tout en me lançant un regard significatif. Quelqu'un, hein? OK, je peux prendre un indice. Je vais essayer. Étant donné ma tendance à expliquer les choses, cela finira probablement par être beaucoup plus long que ce que veut Alan, mais il faut commencer quelque part. Je peux prendre un indice. Je vais essayer. Étant donné ma tendance à expliquer les choses, cela finira probablement par être beaucoup plus long que ce que veut Alan, mais il faut commencer quelque part. Je peux prendre un indice. Je vais essayer. Étant donné ma tendance à expliquer les choses, cela finira probablement par être beaucoup plus long que ce que veut Alan, mais il faut commencer quelque part.

The first thing to confront is that term, “capabilities”, itself. It’s confusing. The word has a perfectly useful everyday meaning, even in the context of software engineering. When I was at PayPal, for example, people would regularly talk about our system’s capabilities, meaning what it can do. And this everyday meaning is actually pretty close to the technical meaning, because in both cases we’re talking about what a system “can” do, but usually what people mean by that is the functionality it realizes rather than the permissions it has been given. One path out of this terminological confusion takes its cue from the natural alignment between capabilities and object oriented programming, since it’s very easy to express capability concepts with object oriented abstractions (I’ll get into this shortly). This has lead, without too much loss of meaning, to the term “object capabilities”, which embraces this affinity. This phrase has the virtue that we can talk about it in abbreviated form as “ocaps” and slough off some of the lexical confusion even further. It does have the downside that there are some historically important capability systems that aren’t really what you’d think of as object oriented, but sometimes oversimplification is the price of clarity. The main thing is, just don’t let the word “capabilities” lead you down the garden path; instead, focus on the underlying ideas.		La première chose à affronter est ce terme lui-même, «capacités». C'est confu. Le mot a une signification quotidienne parfaitement utile, même dans le contexte du génie logiciel. Quand j'étais chez PayPal, par exemple, les gens parlaient régulièrement des capacités de notre système, c'est-à-dire de ce qu'il peut faire. Et cette signification quotidienne est en fait assez proche de la signification technique, car dans les deux cas, nous parlons de ce qu'un système «peut» faire, mais généralement ce que les gens entendent par là est la fonctionnalité qu'il réalise plutôt que les autorisations qui lui ont été accordées. . Un chemin pour sortir de cette confusion terminologique s'inspire de l'alignement naturel entre les capacités et la programmation orientée objet, car il est très facile d'exprimer des concepts de capabilité avec des abstractions orientées objet (j'y reviendrai bientôt). Cela a du plomb, sans trop de perte de sens, au terme de «capacités objet», qui embrasse cette affinité. Cette phrase a le mérite que nous pouvons en parler sous une forme abrégée comme «ocaps» et dissiper encore plus une partie de la confusion lexicale. Cela présente l'inconvénient qu'il existe des systèmes de capacités historiquement importants qui ne sont pas vraiment ce que vous pensez être orientés objet, mais parfois une simplification excessive est le prix de la clarté. L'essentiel est de ne pas laisser le mot «capacités» vous conduire sur le chemin du jardin; concentrez-vous plutôt sur les idées sous-jacentes. Cela présente l'inconvénient qu'il existe des systèmes de capacités historiquement importants qui ne sont pas vraiment ce que vous pensez être orientés objet, mais parfois une simplification excessive est le prix de la clarté. L'essentiel est de ne pas laisser le mot «capacités» vous conduire sur le chemin du jardin; concentrez-vous plutôt sur les idées sous-jacentes. Cela présente l'inconvénient qu'il existe des systèmes de capacités historiquement importants qui ne sont pas vraiment ce que vous pensez être orientés objet, mais parfois une simplification excessive est le prix de la clarté. L'essentiel est de ne pas laisser le mot «capacités» vous conduire sur le chemin du jardin; concentrez-vous plutôt sur les idées sous-jacentes.

The other thing to be aware of is that there’s some controversy surrounding capabilities. Part of this is a natural immune response to criticism (nobody likes being told that they’re doing things all wrong), part of it is academic tribalism at work, and part of it is the engineer’s instinctive and often healthy wariness of novelty. I almost hesitate to mention this (some of my colleagues might argue I shouldn’t have), but it’s important to understand the historical context if you read through the literature. Some of the pushback these ideas have received doesn’t really have as much to do with their actual merits or lack thereof as one might hope; some of it is profoundly incorrect nonsense and should be called out as such.		L'autre chose à savoir, c'est qu'il y a une certaine controverse autour des capacités. Une partie de cela est une réponse immunitaire naturelle à la critique (personne n'aime se faire dire qu'il fait les choses mal), une partie du tribalisme académique au travail, et une partie de cela est la méfiance instinctive et souvent saine de l'ingénieur face à la nouveauté. J'hésite presque à le mentionner (certains de mes collègues diront peut-être que je n'aurais pas dû), mais il est important de comprendre le contexte historique si vous lisez la littérature. Une partie du rejet que ces idées ont reçu n'a pas vraiment autant à voir avec leurs mérites réels ou leur absence que l'on pourrait l'espérer; certaines d'entre elles sont profondément insensées et devraient être dénoncées comme telles.

The idea[edit]		L'idée[ modifier ]

Norm Hardy summarizes the capability mindset with the admonition “don’t separate designation from authority”. I like this a lot, but it’s the kind of zen aphorism that’s mainly useful to people who already understand it. To everybody else, it just invites questions: (a) What does that mean? and (b) Why should I care? So let’s take this apart and see…		Norm Hardy résume la mentalité de capacité avec l'avertissement «ne séparez pas la désignation de l'autorité». J'aime beaucoup ça, mais c'est le genre d'aphorisme zen qui est surtout utile aux gens qui le comprennent déjà. Pour tout le monde, cela ne fait qu'inviter des questions: a) Qu'est-ce que cela signifie? et (b) Pourquoi devrais-je m'en soucier? Alors démontons cela et voyons…

The capability paradigm is about access control. When a system, such as an OS or a website, is presented with a request for a service it provides, it needs to decide if it should actually do what the requestor is asking for. The way it decides is what we’re talking about when we talk about access control. If you’re like most people, the first thing you’re likely to think of is to ask the requestor “who are you?” The fundamental insight of the capabilities paradigm is to recognize that this question is the first step on the road to perdition. That’s highly counterintuitive to most people, hence the related controversy.		Le paradigme des capacités concerne le contrôle d'accès. Lorsqu'un système, tel qu'un système d'exploitation ou un site Web, reçoit une demande de service qu'il fournit, il doit décider s'il doit réellement faire ce que le demandeur demande. La façon dont il décide, c'est ce dont nous parlons lorsque nous parlons de contrôle d'accès. Si vous êtes comme la plupart des gens, la première chose à laquelle vous pensez probablement est de demander au demandeur "qui êtes-vous?" L'idée fondamentale du paradigme des capacités est de reconnaître que cette question est le premier pas sur la voie de la perdition. C'est très contre-intuitif pour la plupart des gens, d'où la controverse connexe.

For example, let’s say you’re editing a document in Microsoft Word, and you click on the “Save” button. This causes Word to issue a request to the operating system to write to the document file. The OS checks if you have write permission for that file and then allows or forbids the operation accordingly. Everybody thinks this is normal and natural. And in this case, it is: you asked Word, a program you chose to run, to write your changes to a file you own. The write succeeded because the operating system’s access control mechanism allowed it on account of it being your file, but that mechanism wasn’t doing quite what you might think. In particular, it didn’t check whether the specific file write operation in question was the one you asked for (because it can’t actually tell), it just checked if you were allowed to do it.		Par exemple, disons que vous modifiez un document dans Microsoft Word et que vous cliquez sur le bouton «Enregistrer». Cela provoque Word pour émettre une demande au système d'exploitation pour écrire dans le fichier de document. Le système d'exploitation vérifie si vous disposez d'une autorisation d'écriture pour ce fichier, puis autorise ou interdit l'opération en conséquence. Tout le monde pense que c'est normal et naturel. Et dans ce cas, c'est: vous avez demandé à Word, un programme que vous avez choisi d'exécuter, d'écrire vos modifications dans un fichier que vous possédez. L'écriture a réussi parce que le mécanisme de contrôle d'accès du système d'exploitation l'autorisait parce qu'il s'agissait de votre fichier, mais ce mécanisme ne faisait pas tout à fait ce que vous pourriez penser. En particulier, il n'a pas vérifié si l'opération d'écriture de fichier spécifique en question était celle que vous aviez demandée (car il ne peut pas réellement le dire), il a simplement vérifié si vous étiez autorisé à le faire.

The access control model here is what’s known as an ACL, which stands for Access Control List. The basic idea is that for each thing the operating system wants to control access to (like a file, for example), it keeps a list of who is allowed to do what. The ACL model is how every current mainstream operating system handles this, so it doesn’t matter if we’re talking about Windows, macOS, Linux, FreeBSD, iOS, Android, or whatever. While there are a lot of variations in the details of how they they handle access control (e.g., the Unix file owner/group/others model, or the principal-per-app model common on phone OSs), in this respect they’re all fundamentally the same.		Le modèle de contrôle d'accès ici est ce qu'on appelle une ACL, qui signifie Access Control List. L'idée de base est que pour chaque chose à laquelle le système d'exploitation veut contrôler l'accès (comme un fichier, par exemple), il garde une liste de qui est autorisé à faire quoi. Le modèle ACL est la façon dont chaque système d'exploitation grand public actuel gère cela, donc peu importe si nous parlons de Windows, macOS, Linux, FreeBSD, iOS, Android ou autre. Bien qu'il existe de nombreuses variantes dans les détails de la façon dont ils gèrent le contrôle d'accès (par exemple, le modèle de propriétaire de fichier / groupe / autres Unix, ou le modèle principal par application commun sur les systèmes d'exploitation de téléphone), à ​​cet égard, ils tous fondamentalement les mêmes.

As I said, this all seems natural and intuitive to most people. It’s also fatally flawed. When you run an application, as far as the OS is concerned, everything the application does is done by you. Another way to put this is, an application you run can do anything you can do. This seems OK in the example we gave of Word saving your file. But what if Word did something else, like transmit the contents of your file over the internet to a server in Macedonia run by the mafia, or erase any of your files whose names begin with a vowel, or encrypt all your files and demand payment in bitcoins to decrypt them? Well, you’re allowed to do all those things, if for some crazy reason you wanted to, so it can too. Now, you might say, we trust Word not to do evil stuff like that. Microsoft would get in trouble. People would talk. And that’s true. But it’s not just Microsoft Word, it’s every single piece of software in your computer, including lots of stuff you don’t even know is there, much of it originating from sources far more difficult to hold accountable than Microsoft Corporation, if you even know who they are at all.		Comme je l'ai dit, tout cela semble naturel et intuitif à la plupart des gens. C'est aussi mortellement défectueux. Lorsque vous exécutez une application, en ce qui concerne le système d'exploitation, tout ce que fait l'application est fait par vous. Une autre façon de dire cela est qu'une application que vous exécutez peut faire tout ce que vous pouvez faire. Cela semble correct dans l'exemple que nous avons donné de Word enregistrant votre fichier. Mais que se passe-t-il si Word faisait autre chose, comme transmettre le contenu de votre fichier sur Internet à un serveur en Macédoine géré par la mafia, ou effacer l'un de vos fichiers dont le nom commence par une voyelle, ou crypter tous vos fichiers et exiger le paiement en des bitcoins pour les décrypter? Eh bien, vous êtes autorisé à faire toutes ces choses, si pour une raison folle vous le vouliez, alors cela peut aussi. Maintenant, vous pourriez dire, nous faisons confiance à Word pour ne pas faire de mauvaises choses comme ça. Microsoft aurait des ennuis. Les gens parlaient. Et c'est vrai.

The underlying problem is that the access control mechanism has no way to determine what you really wanted. One way to deal with this might be to have the operating system ask you for confirmation each time a program wants to do something that is access controlled: “Is it OK for Word to write to this file, yes or no?” Experience with this approach has been pretty dismal. Completely aside from the fact that this is profoundly annoying, people quickly become trained to reflexively answer “yes” without a moment’s thought, since that’s almost always the right answer anyway and they just want to get on with whatever they’re doing. Plus, a lot of the access controlled operations a typical program does are internal things (like fiddling with a configuration file, for example) whose appropriateness the user has no way to determine anyhow.		Le problème sous-jacent est que le mécanisme de contrôle d'accès n'a aucun moyen de déterminer ce que vous vouliez vraiment. Une façon de résoudre ce problème peut être que le système d'exploitation vous demande une confirmation chaque fois qu'un programme souhaite effectuer une opération dont l'accès est contrôlé: "Est-ce que Word peut écrire dans ce fichier, oui ou non?" L'expérience de cette approche a été assez lamentable. Complètement mis à part le fait que cela est profondément ennuyeux, les gens sont rapidement formés pour répondre par réflexe «oui» sans un instant de réflexion, car c'est presque toujours la bonne réponse de toute façon et ils veulent juste continuer ce qu'ils font. De plus, la plupart des opérations de contrôle d'accès effectuées par un programme typique sont des choses internes (comme manipuler un fichier de configuration, par exemple) dont l'utilisateur n'a aucun moyen de déterminer la pertinence.

An alternative approach starts by considering how you told Word what you wanted in the first place. When you first opened the document for editing, you typically either double-clicked on an icon representing the file, or picked the file from an Open File dialog. Note, by the way, that both of these user interface interactions are typically implemented by the operating system (or by libraries provided by the operating system), not by Word. The way current APIs work, what happens in either of these cases is that the operating system provides the application with a character string: the pathname of the file you chose. The application is then free to use this string however it likes, typically passing it as a parameter to another operating system API call to open the file. But this is actually a little weird: you designated a file, but the operating system turned this into a character string which it gave to Word, and then when Word actually wanted to open the file it passed the string back to the operating system, which converted it back into a file again. As I’ve said, this works fine in the normal case. But Word is not actually limited to using just the string that names the particular file you specified. It can pass any string it chooses to the Open File call, and the only access limitation it has is what permissions you have. If it’s your own computer, that’s likely to be permissions to everything on the machine, but certainly it’s at least permissions to all your stuff.		Une approche alternative commence par considérer comment vous avez dit à Word ce que vous vouliez en premier lieu. Lorsque vous avez ouvert le document pour la première fois pour le modifier, vous avez généralement soit double-cliqué sur une icône représentant le fichier, soit sélectionné le fichier dans une boîte de dialogue Ouvrir un fichier. Notez, en passant, que ces deux interactions d'interface utilisateur sont généralement implémentées par le système d'exploitation (ou par les bibliothèques fournies par le système d'exploitation), pas par Word. La façon dont fonctionnent les API actuelles, ce qui se passe dans l'un ou l'autre de ces cas est que le système d'exploitation fournit à l'application une chaîne de caractères: le chemin du fichier que vous avez choisi. L'application est alors libre d'utiliser cette chaîne comme bon lui semble, en la transmettant généralement en tant que paramètre à un autre appel d'API du système d'exploitation pour ouvrir le fichier. Mais c'est en fait un peu bizarre: vous avez désigné un fichier, mais le système d'exploitation l'a transformé en une chaîne de caractères qu'il a donnée à Word, puis lorsque Word voulait réellement ouvrir le fichier, il a renvoyé la chaîne au système d'exploitation, qui l'a reconvertie en fichier. Comme je l'ai dit, cela fonctionne bien dans le cas normal. Mais Word ne se limite pas réellement à utiliser uniquement la chaîne qui nomme le fichier particulier que vous avez spécifié. Il peut transmettre n'importe quelle chaîne de son choix à l'appel Open File, et la seule limitation d'accès dont il dispose sont les autorisations dont vous disposez. S'il s'agit de votre propre ordinateur, il s'agit probablement d'autorisations sur tout ce qui se trouve sur la machine, mais il s'agit certainement au moins d'autorisations sur toutes vos affaires. qui l'a reconverti en fichier. Comme je l'ai dit, cela fonctionne bien dans le cas normal. Mais Word ne se limite pas réellement à utiliser uniquement la chaîne qui nomme le fichier particulier que vous avez spécifié. Il peut transmettre n'importe quelle chaîne de son choix à l'appel Open File, et la seule limitation d'accès dont il dispose sont les autorisations dont vous disposez. S'il s'agit de votre propre ordinateur, il s'agit probablement d'autorisations sur tout ce qui se trouve sur la machine, mais il s'agit certainement au moins d'autorisations sur toutes vos affaires. qui l'a reconverti en fichier. Comme je l'ai dit, cela fonctionne bien dans le cas normal. Mais Word ne se limite pas réellement à utiliser uniquement la chaîne qui nomme le fichier particulier que vous avez spécifié. Il peut transmettre n'importe quelle chaîne de son choix à l'appel Open File, et la seule limitation d'accès dont il dispose sont les autorisations dont vous disposez. S'il s'agit de votre propre ordinateur, il s'agit probablement d'autorisations sur tout ce qui se trouve sur la machine, mais il s'agit certainement au moins d'autorisations sur toutes vos affaires.

Now imagine things working a little differently. Imagine that when Word starts running it has no access at all to anything that’s access controlled – no files, peripheral devices, networks, nothing. When you double click the file icon or pick from the open file dialog, instead of giving Word a pathname string, the operating system itself opens the file and gives Word a handle to it (that is, it gives Word basically the same thing it would have given Word in response to the Open File API call when doing things the old way). Now Word has access to your document, but that’s all. It can’t send your file to Macedonia, because it doesn’t have access to the network – you didn’t give it that, you just gave it the document. It can’t delete or encrypt any of your other files, because it wasn’t given access to any of them either. It can mess up the one file you told it to edit, but it’s just the one file, and if it did that you’d stop using Word and not suffer any further damage. And notice that the user experience – your experience – is exactly the same as it was before. You didn’t have to answer any “mother may I?” security questions or put up with any of the other annoying stuff that people normally associate with security. In this world, that handle to the open file is an example of what we call a “capability”.		Maintenant, imaginez que les choses fonctionnent un peu différemment. Imaginez que lorsque Word commence à s'exécuter, il n'a aucun accès à tout ce dont l'accès est contrôlé - pas de fichiers, de périphériques, de réseaux, rien. Lorsque vous double-cliquez sur l'icône du fichier ou sélectionnez dans la boîte de dialogue Ouvrir le fichier, au lieu de donner à Word une chaîne de chemin d'accès, le système d'exploitation lui-même ouvre le fichier et lui donne un descripteur à Word (c'est-à-dire qu'il donne à Word fondamentalement la même chose qu'il le ferait. ont donné Word en réponse à l'appel de l'API Open File lorsque vous faites les choses à l'ancienne). Maintenant, Word a accès à votre document, mais c'est tout. Il ne peut pas envoyer votre fichier en Macédoine, car il n'a pas accès au réseau - vous ne lui avez pas donné cela, vous venez de lui donner le document. Il ne peut supprimer ni chiffrer aucun de vos autres fichiers, car il n'a pas non plus accès à aucun d'entre eux. Cela peut gâcher le fichier que vous lui avez dit de modifier, mais ce n'est que le seul fichier, et si c'était le cas, vous arrêteriez d'utiliser Word et ne subiriez plus de dommages. Et notez que l'expérience utilisateur - votre expérience - est exactement la même qu'avant. Vous n'aviez pas à répondre à une «mère, puis-je?» des questions de sécurité ou des autres trucs ennuyeux que les gens associent normalement à la sécurité. Dans ce monde, ce descripteur du fichier ouvert est un exemple de ce que nous appelons une «capacité». Vous n'aviez pas à répondre à une «mère, puis-je?» des questions de sécurité ou des autres trucs ennuyeux que les gens associent normalement à la sécurité. Dans ce monde, ce descripteur du fichier ouvert est un exemple de ce que nous appelons une «capacité». Vous n'aviez pas à répondre à une «mère, puis-je?» des questions de sécurité ou des autres trucs ennuyeux que les gens associent normalement à la sécurité. Dans ce monde, ce descripteur du fichier ouvert est un exemple de ce que nous appelons une «capacité».

This is where we get back to Norm Hardy’s “don’t separate designation from authority” motto. By “designation” we mean how we indicate to, for example, the OS, which thing we are talking about. By “authority” we mean what we are allowed by the OS to do with that thing. In the traditional ACL world, these are two largely disconnected concepts. In the case of a file, the designator is typically a pathname – a character string – that you use to refer to the file when operating upon it. The OS provides operations like Write File or Delete File that are parameterized by the path name of the file to be written to or deleted. Authority is managed separately as an ACL that the OS maintains in association with each file. This means that the decision to grant access to a file is unrelated to the decision to make use of it. But this in turn means that the decision to grant access has to be made without knowledge of the specific uses. It means that the two pieces of information the operating system needs in order to make its access control decision travel to it via separate routes, with no assurance that they will be properly associated with each other when they arrive. In particular, it means that a program can often do things (or be fooled into doing things) that were never intended to be allowed.		C'est là que nous revenons à la devise de Norm Hardy «ne pas séparer la désignation de l'autorité». Par «désignation», nous entendons la façon dont nous indiquons, par exemple, au système d'exploitation, de quoi nous parlons. Par «autorité», nous entendons ce que le système d'exploitation nous autorise à faire avec cette chose. Dans le monde ACL traditionnel, ce sont deux concepts largement déconnectés. Dans le cas d'un fichier, l'indicateur est généralement un chemin d'accès - une chaîne de caractères - que vous utilisez pour faire référence au fichier lorsque vous l'utilisez. Le système d'exploitation fournit des opérations telles que Écrire un fichier ou Supprimer un fichier qui sont paramétrées par le nom de chemin du fichier dans lequel écrire ou supprimer. L'autorité est gérée séparément en tant qu'ACL que le système d'exploitation gère en association avec chaque fichier. Cela signifie que la décision d'accorder l'accès à un dossier n'a aucun lien avec la décision d'en faire usage. Mais cela signifie à son tour que la décision d'accorder l'accès doit être prise sans connaissance des utilisations spécifiques. Cela signifie que les deux informations dont le système d'exploitation a besoin pour prendre sa décision de contrôle d'accès y sont acheminées via des itinéraires séparés, sans aucune assurance qu'elles seront correctement associées l'une à l'autre à leur arrivée. En particulier, cela signifie qu'un programme peut souvent faire des choses (ou être dupées en faisant des choses) qui n'ont jamais été censées être autorisées.

Here’s the original example of the kind of thing I’m talking about, a tale from Norm. It’s important to note, by the way, that this is an actual true story, not something I just made up for pedagogical purposes.		Voici l'exemple original du genre de chose dont je parle, un conte de Norm. Il est important de noter, en passant, que c'est une histoire vraie et vraie, pas quelque chose que j'ai juste inventé à des fins pédagogiques.

Once upon a time, Norm worked for a company that ran a bunch of timeshared computers, kind of like what we now call “cloud computing” only with an earlier generation’s buzzwords. One service they provided was a FORTRAN compiler, so customers could write their own software.		Il était une fois, Norm a travaillé pour une entreprise qui exploitait un tas d'ordinateurs en temps partagé, un peu comme ce que nous appelons maintenant le «cloud computing» uniquement avec les mots à la mode d'une génération antérieure. Un service qu'ils ont fourni était un compilateur FORTRAN, afin que les clients puissent écrire leur propre logiciel.

It being so many generations of Moore’s Law ago, computing was expensive, so each time the compiler ran it wrote a billing record to a system accounting file noting the resources used, so the customer could be charged for them. Since this was a shared system, the operators knew to be careful with file permissions. So, for example, if you told the compiler to output to a file that belonged to somebody else, this would fail because you didn’t have permission. They also took care to make sure that only the compiler itself could write to the system accounting file – you wouldn’t want random users to mess with the billing records, that would obviously be bad.		Comme il y a tant de générations de la loi de Moore, l'informatique était coûteuse, donc chaque fois que le compilateur exécutait, il écrivait un enregistrement de facturation dans un fichier de comptabilité système en notant les ressources utilisées, afin que le client puisse être facturé. Comme il s'agissait d'un système partagé, les opérateurs savaient qu'il fallait faire attention aux autorisations de fichiers. Ainsi, par exemple, si vous disiez au compilateur de sortir dans un fichier qui appartenait à quelqu'un d'autre, cela échouerait car vous n'aviez pas l'autorisation. Ils ont également pris soin de s'assurer que seul le compilateur lui-même pouvait écrire dans le fichier de comptabilité système - vous ne voudriez pas que des utilisateurs aléatoires gâchent les enregistrements de facturation, ce serait évidemment mauvais.

Then one day somebody figured out they could tell the compiler the name of the system accounting file as the name of the file to write the compilation output to. The access control system looked at this and asked, “does this program have permission to write to this file?” – and it did! And so the compiler was allowed to overwrite the billing records and the billing information was lost and everybody got all their compilations for free that day.		Puis, un jour, quelqu'un a compris qu'il pouvait indiquer au compilateur le nom du fichier de comptabilité système comme nom du fichier dans lequel écrire la sortie de la compilation. Le système de contrôle d'accès a examiné cela et a demandé: «Ce programme a-t-il l'autorisation d'écrire dans ce fichier?» - et ça l'a fait! Ainsi, le compilateur a été autorisé à écraser les enregistrements de facturation et les informations de facturation ont été perdues et tout le monde a obtenu toutes ses compilations gratuitement ce jour-là.

Fixing this turned out to be surprisingly slippery. Norm named the underlying problem “The Confused Deputy”. At heart, the FORTRAN compiler was deputized by two different masters: the customer and the system operators. To serve the customer, it had been given permission to access the customer’s files. To serve the operators, it had been given permission to access the accounting file. But it was confused about which master it was serving for which purpose, because it had no way to associate the permissions it had with their intended uses. It couldn’t specify “use this permission for this file, use that permission for that file”, because the permissions themselves were not distinct things it could wield selectively – the compiler never actually saw or handled them directly. We call this sort of thing “ambient authority”, because it’s just sitting there in the environment, waiting to be used automatically without regard to intent or context.		Réparer ce problème s'est avéré étonnamment glissant. Norm a nommé le problème sous-jacent «l'adjoint confus». Au fond, le compilateur FORTRAN était suppléé par deux maîtres différents: le client et les opérateurs système. Pour servir le client, il avait reçu l'autorisation d'accéder aux fichiers du client. Pour servir les opérateurs, il avait été autorisé à accéder au dossier comptable. Mais il était confus quant à savoir quel maître il servait dans quel but, car il n'avait aucun moyen d'associer les autorisations dont il disposait à leurs utilisations prévues. Il ne pouvait pas spécifier «utiliser cette autorisation pour ce fichier, utiliser cette autorisation pour ce fichier», car les autorisations elles-mêmes n'étaient pas des choses distinctes qu'il pouvait exercer de manière sélective - le compilateur ne les a jamais réellement vues ou traitées directement. Nous appelons ce genre de chose «autorité ambiante»,

If this system had been built on capability principles, rather than accessing the files by name, the compiler would instead have been given a capability by the system operators to access the accounting file with, which it would use to update the billing records, and then gotten a different capability from the customer to access the output file, which it would use when outputting the result of the compilation. There would have been no confusion and no exploit.		Si ce système avait été construit sur des principes de capacité, plutôt que d'accéder aux fichiers par nom, le compilateur aurait plutôt reçu une capacité par les opérateurs du système d'accéder au fichier comptable avec, qu'il utiliserait pour mettre à jour les enregistrements de facturation, puis obtenu une capacité différente du client pour accéder au fichier de sortie, qu'il utiliserait lors de la sortie du résultat de la compilation. Il n'y aurait eu ni confusion ni exploit.

You might think this is some obscure problem those old people had back somewhere at the dawn of the industry, but a whole bunch of security problems plaguing us today – which you might think are all very different – fit this template, including many kinds of injection attacks, cross-site request forgery, cross site scripting attacks, click-jacking – including, depending on how you look at it, somewhere between 5 and 8 members of the OWASP top 10 list. These are all arguably confused deputy problems, manifestations of this one conceptual flaw first noticed in the 1970s!		Vous pourriez penser que c'est un problème obscur que ces personnes âgées avaient quelque part à l'aube de l'industrie, mais tout un tas de problèmes de sécurité qui nous affligent aujourd'hui - que vous pourriez penser sont tous très différents - correspondent à ce modèle, y compris de nombreux types d'injection attaques, falsification de requêtes intersites, attaques de scripts intersites, piratage de clics - y compris, selon la façon dont vous le regardez, quelque part entre 5 et 8 membres de la liste des 10 meilleurs de l'OWASP. Ce sont tous des problèmes d'adjoint sans doute confus, des manifestations de cette faille conceptuelle remarquée pour la première fois dans les années 1970!

Getting more precise[edit]		Devenir plus précis[ modifier ]

We said separating designation from authority is dangerous, and that instead these two things should be combined, but we didn’t really say much about what it actually means to combine them. So at this point I think it’s time to get a bit more precise about what a capability actually is.		Nous avons dit qu'il était dangereux de séparer la désignation de l'autorité et que ces deux choses devraient plutôt être combinées, mais nous n'avons pas vraiment dit grand-chose sur ce que cela signifie réellement de les combiner. Donc, à ce stade, je pense qu'il est temps d'être un peu plus précis sur ce qu'est réellement une capacité.

A capability is single thing that both designates a resource and authorizes some kind of access to it.		Une capacité est une chose unique qui désigne à la fois une ressource et autorise un certain type d'accès à celle-ci.

There’s a bunch of abstract words in there, so let’s unpack it a bit.		Il y a un tas de mots abstraits là-dedans, alors décompressons-le un peu.

By resource we just mean something the access control mechanism controls access to. It’s some specific thing we have that somebody might want to use somehow, whose use we seek to regulate. It could be a file, an I/O device, a network connection, a database record, or really any kind of object. The access control mechanism itself doesn’t much care what kind of thing the resource is or what someone wants to do with it. In specific use cases, of course, we care very much about those things, but then we’re talking about what we use the access control mechanism for, not about how it works.		Par ressource, nous entendons simplement quelque chose auquel le mécanisme de contrôle d'accès contrôle l'accès. C'est une chose spécifique que nous avons que quelqu'un pourrait vouloir utiliser d'une manière ou d'une autre, dont nous cherchons à réglementer l'utilisation. Il peut s'agir d'un fichier, d'un périphérique d'E / S, d'une connexion réseau, d'un enregistrement de base de données ou de tout type d'objet. Le mécanisme de contrôle d'accès lui-même ne se soucie pas beaucoup du type de chose de la ressource ou de ce que quelqu'un veut en faire. Dans des cas d'utilisation spécifiques, bien sûr, nous nous soucions beaucoup de ces choses, mais nous parlons ensuite de ce pour quoi nous utilisons le mécanisme de contrôle d'accès, pas de son fonctionnement.

In the same vein, when we talk about access, we just mean actually doing something that can be done with the resource. Access could be reading, writing, invoking, using, destroying, activating, or whatever. Once again, which of these it is is important for specific uses but not for the mechanism itself. Also, keep in mind that the specific kind of access that’s authorized is one of the things the capability embodies. Thus, for example, a read capability to a file is a different thing from a write capability to the same file (and of course, there might be a read+write capability to that file, which would be yet a third thing).		Dans la même veine, lorsque nous parlons d'accès, nous entendons simplement faire quelque chose qui peut être fait avec la ressource. L'accès peut être la lecture, l'écriture, l'invocation, l'utilisation, la destruction, l'activation ou autre. Encore une fois, lequel de ces éléments est important pour des utilisations spécifiques mais pas pour le mécanisme lui-même. N'oubliez pas non plus que le type d'accès spécifique autorisé fait partie des éléments incarnés par la capacité. Ainsi, par exemple, une capacité de lecture dans un fichier est une chose différente d'une capacité d'écriture dans le même fichier (et bien sûr, il pourrait y avoir une capacité de lecture + écriture dans ce fichier, ce qui serait encore une troisième chose).

By designation, we mean indicating, somehow, specifically which resource we’re talking about. And by authorizing we mean that we are allowing the access to happen. Hopefully, none of this is any surprise.		Par désignation, nous entendons indiquer, d'une manière ou d'une autre, précisément de quelle ressource nous parlons. Et en autorisant, nous voulons dire que nous autorisons l'accès. Espérons que rien de tout cela n'est une surprise.

Because the capability combines designation with authority, the possessor of the capability exercises their authority – that is, does whatever it is they are allowed to do with the resource the capability is a capability to – by wielding the capability itself. (What that means in practice should be clearer after a few examples). If you don’t possess the capability, you can’t use it, and thus you don’t have access. Access is regulated by controlling possession.		Parce que la capacité combine la désignation et l'autorité, le détenteur de la capacité exerce son autorité - c'est-à-dire fait tout ce qu'il est autorisé à faire avec la ressource pour laquelle la capacité est une capacité - en utilisant la capacité elle-même. (Ce que cela signifie en pratique devrait être plus clair après quelques exemples). Si vous ne possédez pas la capacité, vous ne pouvez pas l'utiliser et vous n'y avez donc pas accès. L'accès est réglementé par le contrôle de la possession.

A key idea is that capabilities are transferrable, that someone who possesses a capability can convey it to someone else. An important implication that falls out of this is that capabilities fundamentally enable delegation of authority. If you are able to do something, it means you possess a capability for that something. If you pass this capability to somebody else, then they are now also able do whatever it is. Delegation is one of the main things that make capabilities powerful and useful. However, it also tends to cause a lot of people to freak out at the apparent loss of control. A common response is to try to invent mechanisms to limit or forbid delegation, which is a terrible idea and won’t work anyway, for reasons I’ll get into.		Une idée clé est que les capacités sont transférables, que quelqu'un qui possède une capacité peut la transmettre à quelqu'un d'autre. Une implication importante qui en découle est que les capacités permettent fondamentalement la délégation de pouvoirs. Si vous êtes capable de faire quelque chose, cela signifie que vous possédez une capacité pour ce quelque chose. Si vous transmettez cette capacité à quelqu'un d'autre, il est désormais également en mesure de faire quoi que ce soit. La délégation est l'un des principaux éléments qui rendent les capacités puissantes et utiles. Cependant, cela a également tendance à faire paniquer beaucoup de gens face à la perte de contrôle apparente. Une réponse courante est d'essayer d'inventer des mécanismes pour limiter ou interdire la délégation, ce qui est une idée terrible et qui ne fonctionnera pas de toute façon, pour des raisons que je vais aborder.

If you’re one of these people, please don’t freak out yourself; I’ll come back to this shortly and explain some important capability patterns that hopefully will address your concerns. In the meantime, a detail that might be helpful to meditate on: two capabilities that authorize the same access to the same resource are not necessarily the same capability (note: this is just a hint to tease the folks who are trying to guess where this goes, so if you’re not one of those people, don’t worry if it’s not obvious).		Si vous faites partie de ces personnes, ne vous inquiétez pas; J'y reviendrai sous peu et vous expliquerai quelques modèles de capacités importants qui, nous l'espérons, répondront à vos préoccupations. En attendant, un détail sur lequel il pourrait être utile de méditer: deux capacités qui autorisent le même accès à la même ressource ne sont pas nécessairement la même capacité (note: il ne s'agit que d'un indice pour taquiner les gens qui essaient de deviner où cela va, donc si vous n'êtes pas l'une de ces personnes, ne vous inquiétez pas si ce n'est pas évident).

Another implication of our definition is that capabilities must be unforgeable. By this we mean that you can’t by yourself create a capability to a resource that you don’t already have access to. This is a basic requirement that any capability system must satisfy. For example, using pathnames to designate files is problematic because anybody can create any character string they want, which means they can designate any file they want if pathnames are how you do it. Pathnames are highly forgeable. They work fine as designators, but can’t by themselves be used to authorize access. In the same vein, an object pointer in C++ is forgeable, since you can typecast an integer into a pointer and thus produce a pointer to any kind of object at any memory address of your choosing, whereas in Java, Smalltalk, or pretty much any other memory-safe language where this kind of casting is not available, an object reference is unforgeable.		Une autre implication de notre définition est que les capacités doivent être infalsifiables. Nous entendons par là que vous ne pouvez pas créer vous-même une capacité à une ressource à laquelle vous n'avez pas déjà accès. Il s'agit d'une exigence de base que tout système de capacité doit satisfaire. Par exemple, l'utilisation de chemins pour désigner des fichiers est problématique parce que n'importe qui peut créer n'importe quelle chaîne de caractères de son choix, ce qui signifie qu'il peut désigner n'importe quel fichier de son choix si les noms de chemin sont comme vous le faites. Les noms de chemin sont hautement falsifiés. Ils fonctionnent bien en tant qu'indicateurs, mais ne peuvent pas être utilisés à eux seuls pour autoriser l'accès. Dans la même veine, un pointeur d'objet en C ++ est forgeable, car vous pouvez taper un entier en pointeur et ainsi produire un pointeur vers n'importe quel type d'objet à n'importe quelle adresse mémoire de votre choix, alors qu'en Java, Smalltalk,

As I’ve talked about all this, I’ve tended to personify the entities that possess, transfer, and wield capabilities – for example, sometimes by referring to one of them as “you”. This has let me avoid saying much about what kind of entities these are. I did this so you wouldn’t get too anchored in specifics, because there are many different ways capability systems can work, and the kinds of actors that populate these systems vary. In particular, personification let me gloss over whether these actors were bits of software or actual people. However, we’re ultimately interested in building software, so now lets talk about these entities as “objects”, in the traditional way we speak of objects in object oriented programming. By getting under the hood a bit, I hope things may be made a little easier to understand. Later on we can generalize to other kinds of systems beyond OOP.		En parlant de tout cela, j'ai eu tendance à personnifier les entités qui possèdent, transfèrent et manient des capacités - par exemple, parfois en faisant référence à l'une d'elles comme «vous». Cela m'a permis d'éviter de trop dire de quel type d'entités il s'agit. J'ai fait cela pour que vous ne soyez pas trop ancré dans les détails, car il existe de nombreuses façons différentes que les systèmes de capacités peuvent fonctionner, et les types d'acteurs qui peuplent ces systèmes varient. En particulier, la personnification m'a permis de passer sous silence si ces acteurs étaient des morceaux de logiciels ou des personnes réelles. Cependant, nous sommes finalement intéressés par la création de logiciels, alors parlons maintenant de ces entités comme des «objets», de la manière traditionnelle que nous parlons d'objets dans la programmation orientée objet. En me mettant un peu sous le capot, j'espère que les choses pourront être un peu plus faciles à comprendre.

I’ll alert you now that I’ll still tend to personify these things a bit. It’s helpful for us humans, in trying to understand the actions of an intentional agent, to think of it as if it’s a person even if it’s really code. Plus – and I’ll admit to some conceptual ju-jitsu here – we really do want to talk about objects as distinct intentional agents. Another of the weaknesses of the ACL approach is that it roots everything in the identity of the user (or other vaguely user-like abstractions like roles, groups, service accounts, and so on) as if that user was the one doing things, that is, as if the user is the intentional agent. However, when an object actually does something it does it in a particular way that depends on how it is coded. While this behavior might reflect the intentions of the specific user who ultimately set it in motion, it might as easily reflect the intentions of the programmers who wrote it – more often, in fact, because most of what a typical piece of software does involves internal mechanics that we often work very hard to shield the user from having to know anything about.		Je vous alerterai maintenant que j'aurai encore tendance à personnifier un peu ces choses. C'est utile pour nous, humains, en essayant de comprendre les actions d'un agent intentionnel, de penser à lui comme s'il s'agissait d'une personne même si c'est vraiment du code. De plus - et j'admets ici quelques ju-jitsu conceptuels - nous voulons vraiment parler des objets en tant qu'agents intentionnels distincts. Une autre des faiblesses de l'approche ACL est qu'elle enracine tout dans l'identité de l'utilisateur (ou d'autres abstractions vaguement semblables à l'utilisateur comme les rôles, les groupes, les comptes de service, etc.) comme si cet utilisateur était celui qui faisait les choses, que est, comme si l'utilisateur était l'agent intentionnel. Cependant, lorsqu'un objet fait réellement quelque chose, il le fait d'une manière particulière qui dépend de la façon dont il est codé. Bien que ce comportement puisse refléter les intentions de l'utilisateur spécifique qui l'a finalement mis en mouvement,

In what we’re calling an “object capability” system (or “ocap” system, to use the convenient contraction I mentioned in the beginning), a reference to an object is a capability. The interesting thing about objects in such a system is that they are both wielders of capabilities and resources themselves. An object wields a capability – an object reference – by invoking methods on it. You transfer a capability by passing an object reference as a parameter in a method invocation, returning it from a method, or by storing it in a variable. An ocap system goes beyond an ordinary OOP system by imposing a couple additional requirements: (1) that object references be unforgeable, as just discussed, and (2) that there be some means of strong encapsulation, so that one object can hold onto references to other objects in a way that these can’t be accessed from outside it. For example, you can implement ocap principles in Java using ordinary Java object references held in private instance variables (to make Java itself into a pure ocap language – which you can totally do, by the way – requires introducing a few additional rules, but that’s more detail than we have time for here).		Dans ce que nous appelons un système de «capacité d'objet» (ou système «ocap», pour utiliser la contraction commode que j'ai mentionnée au début), une référence à un objet est une capacité. La chose intéressante à propos des objets dans un tel système est qu'ils sont à la fois des détenteurs de capacités et de ressources. Un objet utilise une capacité - une référence d'objet - en invoquant des méthodes dessus. Vous transférez une capacité en passant une référence d'objet en tant que paramètre dans un appel de méthode, en la renvoyant à partir d'une méthode ou en la stockant dans une variable. Un système ocap va au-delà d'un système POO ordinaire en imposant quelques exigences supplémentaires: (1) que les références d'objet soient infalsifiables, comme nous venons de le voir, et (2) qu'il existe des moyens d'encapsulation forte, afin qu'un objet puisse conserver des références à d'autres objets de manière à ce que ceux-ci ne soient pas accessibles de l'extérieur. Par exemple, vous pouvez implémenter les principes ocap en Java en utilisant des références d'objet Java ordinaires contenues dans des variables d'instance privées (pour faire de Java lui-même un langage ocap pur - ce que vous pouvez totalement faire, d'ailleurs - nécessite l'introduction de quelques règles supplémentaires, mais c'est plus de détails que nous n'avons le temps ici).

In an ocap system, there are only three possible ways you can come to have a capability to some resource, which is to say, to have a reference to some object: creation, transfer, and endowment.		Dans un système d'ocap, il n'y a que trois façons possibles de parvenir à avoir une capacité à une ressource, c'est-à-dire d'avoir une référence à un objet: la création, le transfert et la dotation.

Creation means you created the resource yourself. We follow the convention that, as a byproduct of the act of creation, the creator receives a capability that provides full access to the new resource. This is natural in an OOP system, where an object constructor typically returns a reference to the new object it constructed. In a sense, creation is an optional feature, because it’s not actually a requirement that a capability system have a way to produce new resources at all (that is, it might be limited to resources that already exist), but if it does, there needs to be way for the new resources to enter into the capability world, and handing them to their creator is a good way to do it.		La création signifie que vous avez créé la ressource vous-même. Nous suivons la convention selon laquelle, en tant que sous-produit de l'acte de création, le créateur reçoit une capacité qui donne un accès complet à la nouvelle ressource. Cela est naturel dans un système POO, où un constructeur d'objet renvoie généralement une référence au nouvel objet qu'il a construit. Dans un sens, la création est une fonctionnalité facultative, car ce n'est pas en fait une exigence qu'un système de capacités ait un moyen de produire de nouvelles ressources (c'est-à-dire qu'elle peut être limitée aux ressources qui existent déjà), mais si c'est le cas, il doit être un moyen pour les nouvelles ressources d'entrer dans le monde des capacités, et les remettre à leur créateur est une bonne façon de le faire.

Transfer means somebody else gave the capability to you. This is the most important and interesting case. Capability passing is how the authority graph – the map of who has what authority to do what with what – can change over time (by the way, the lack of a principled way to talk about how authorities change over time is another big problem with the ACL model). The simple idea is: Alice has a capability to Bob, Alice passes this capability to Carol, now Carol also has a capability to Bob. That simple narrative, however, conceals some important subtleties. First, Alice can only do this if she actually possesses the capability to Bob in the first place. Hopefully this isn’t surprising, but it is important. Second, Alice also has to have a capability to Carol (or some capability to communicate with Carol, which amounts to the same thing). Now things get interesting; it means we have a form of confinement, in that you can’t leak a capability unless you have another capability that lets you communicate with someone to whom you’d leak it. Third, Alice had to choose to pass the capability on; neither Bob nor Carol (nor anyone else) could cause the transfer without Alice’s participation (this is what motivates the requirement for strong encapsulation).		Le transfert signifie que quelqu'un d'autre vous a donné la capacité. C'est le cas le plus important et le plus intéressant. Le dépassement des capacités est la façon dont le graphe d'autorité - la carte de qui a quelle autorité pour faire quoi avec quoi - peut changer au fil du temps (en passant, l'absence de manière raisonnée de parler de la façon dont les autorités changent au fil du temps est un autre gros problème avec le Modèle ACL). L'idée simple est: Alice a une capacité à Bob, Alice transmet cette capacité à Carol, maintenant Carol a également une capacité à Bob. Ce récit simple, cependant, cache certaines subtilités importantes. Premièrement, Alice ne peut le faire que si elle possède réellement la capacité de Bob en premier lieu. J'espère que ce n'est pas surprenant, mais c'est important. Deuxièmement, Alice doit également avoir une capacité de Carol (ou une capacité de communiquer avec Carol, ce qui revient au même). Maintenant, les choses deviennent intéressantes; cela signifie que nous avons une forme de confinement, en ce sens que vous ne pouvez pas divulguer une capacité à moins d'avoir une autre capacité qui vous permet de communiquer avec quelqu'un à qui vous la divulguer. Troisièmement, Alice a dû choisir de transmettre la capacité; ni Bob ni Carol (ni personne d'autre) ne pourraient provoquer le transfert sans la participation d'Alice (c'est ce qui motive l'exigence d'une encapsulation forte).

Endowment means you were born with the capability. An object’s creator can give it a reference to some other object as part of its initial state. In one sense, this is just creation followed by transfer. However, we treat endowment as its own thing for a couple of reasons. First, it’s how we can have an immutable object that holds a capability. Second, it’s how we avoid infinite regress when we follow the rules to their logical conclusion.		La dotation signifie que vous êtes né avec la capacité. Le créateur d'un objet peut lui donner une référence à un autre objet dans le cadre de son état initial. Dans un sens, ce n'est qu'une création suivie d'un transfert. Cependant, nous considérons la dotation comme sa propre chose pour plusieurs raisons. Premièrement, c'est comment nous pouvons avoir un objet immuable qui détient une capacité. Deuxièmement, c'est ainsi que nous évitons une régression infinie lorsque nous suivons les règles jusqu'à leur conclusion logique.

Endowment is how objects end up with capabilities that are realized by the ocap system implementation itself rather by code executing within it. What this means varies depending on the nature of the system; for example, an ocap language framework running on a conventional OS might provide a capability-oriented interface to the OS’s non-capability-oriented file system. An ocap operating system (such as KeyKOS or seL4) might provide capability-oriented access to primitive hardware resources such as disk blocks or network interfaces. In both cases we’re talking about things that exist outside the ocap model, which must be wrapped in special privileged objects that have native access to those things. Such objects can’t be created within the ocap rules, so they have to be endowed by the system itself.		La dotation est la façon dont les objets se retrouvent avec des capacités qui sont réalisées par l'implémentation du système ocap elle-même plutôt que par le code qui s'exécute en son sein. Ce que cela signifie varie selon la nature du système; par exemple, un framework de langage ocap fonctionnant sur un système d'exploitation conventionnel peut fournir une interface orientée capacités vers le système de fichiers non orienté capacités du système d'exploitation. Un système d'exploitation ocap (tel que KeyKOS ou seL4) peut fournir un accès orienté capacités aux ressources matérielles primitives telles que des blocs de disque ou des interfaces réseau. Dans les deux cas, nous parlons de choses qui existent en dehors du modèle ocap, qui doivent être enveloppées dans des objets privilégiés spéciaux qui ont un accès natif à ces choses. De tels objets ne peuvent pas être créés dans les règles d'ocap, ils doivent donc être dotés par le système lui-même.

So, to summarize: in the ocap model, a resource is an object and a capability is an object reference. The access that a given capability enables is the method interface that the object reference exposes. Another way to think of this is: ocaps are just object oriented programming with some additional strictness.		Donc, pour résumer: dans le modèle ocap, une ressource est un objet et une capacité est une référence d'objet. L'accès qu'une capacité donnée permet est l'interface de méthode que la référence d'objet expose. Une autre façon de voir cela est: les ocaps sont juste une programmation orientée objet avec une certaine rigueur supplémentaire.

Here we come to another key difference from the ACL model: in the ocap world, the kinds of resources that may be access controlled, and the varieties of access to them that can be provided, are typically more diverse and more finely grained. They’re also generally more dynamic, since it’s usually possible, and indeed normal, to introduce new kinds of resources over time, with new kinds of access affordances, simply by defining new object classes. In contrast, the typical ACL framework has a fixed set of resource types baked into it, along with a small set of access modes that can be separately controlled. This difference is not fundamental – you could certainly create an extensible ACL system or an ocap framework based on a small, static set of object types – but it points to an important philosophical divergence between the two approaches.		Nous arrivons ici à une autre différence clé par rapport au modèle ACL: dans le monde ocap, les types de ressources dont l'accès peut être contrôlé, et les variétés d'accès qui peuvent être fournies, sont généralement plus diversifiés et plus finement granulés. Ils sont également généralement plus dynamiques, car il est généralement possible, voire normal, d'introduire de nouveaux types de ressources au fil du temps, avec de nouveaux types d'affordances d'accès, simplement en définissant de nouvelles classes d'objets. En revanche, le framework ACL typique contient un ensemble fixe de types de ressources intégrés, ainsi qu'un petit ensemble de modes d'accès qui peuvent être contrôlés séparément. Cette différence n'est pas fondamentale - vous pourriez certainement créer un système ACL extensible ou un framework ocap basé sur un petit ensemble statique de types d'objets - mais elle indique une divergence philosophique importante entre les deux approches.

In the ACL model, access decisions are made on the basis of access configuration settings associated with the resources. These settings must be administered, often manually, by direct interaction with the access control machinery, typically using tools that are part of the access control system itself. While policy abstractions (such as groups or roles, for example) can reduce the need for humans to make large numbers of individual configuration decisions, it is typically the case that each resource acquires its access control settings as the consequence of people making deliberate access configuration choices for it.		Dans le modèle ACL, les décisions d'accès sont prises sur la base des paramètres de configuration d'accès associés aux ressources. Ces paramètres doivent être administrés, souvent manuellement, par interaction directe avec la machinerie de contrôle d'accès, généralement à l'aide d'outils faisant partie du système de contrôle d'accès lui-même. Alors que les abstractions de politique (telles que les groupes ou les rôles, par exemple) peuvent réduire le besoin pour les humains de prendre un grand nombre de décisions de configuration individuelles, il est généralement le cas où chaque ressource acquiert ses paramètres de contrôle d'accès à la suite de la configuration de l'accès délibérée choix pour cela.

In contrast, the ocap approach dispenses with most of this configuration information and its attendant administrative activity. The vast majority of access control decisions are realized by the logic of how the resources themselves operate. Most access control choices are subsumed by the code of the corresponding objects. At the granularity of individual objects, the decisions to be made are usually simple and clear from context, further reducing the cognitive burden. Only at the periphery, where the system comes into actual contact with its human users, do questions of policy and human intent arise. And in many of these cases, intent can be inferred from the normal acts of control and designation that users make through their normal UI interactions (such as picking a file from a dialog or clicking on a save button, to return to the example we began with).		En revanche, l'approche ocap supprime la plupart de ces informations de configuration et son activité administrative associée. La grande majorité des décisions de contrôle d'accès sont réalisées par la logique du fonctionnement des ressources elles-mêmes. La plupart des choix de contrôle d'accès sont subsumés par le code des objets correspondants. Au niveau de la granularité des objets individuels, les décisions à prendre sont généralement simples et claires du contexte, ce qui réduit encore le fardeau cognitif. Ce n'est qu'à la périphérie, là où le système entre en contact réel avec ses utilisateurs humains, que se posent des questions de politique et d'intention humaine. Et dans beaucoup de ces cas, l'intention peut être déduite des actes normaux de contrôle et de désignation que les utilisateurs effectuent via leurs interactions d'interface utilisateur normales (comme choisir un fichier dans une boîte de dialogue ou cliquer sur un bouton d'enregistrement,

Consequently, thinking about access control policy and administration is an entirely different activity in an ocap system than in an ACL system. This thinking extends into the fundamental architecture of applications themselves, as well as that of things like programming languages, application frameworks, network protocols, and operating systems.		Par conséquent, la réflexion sur la politique de contrôle d'accès et l'administration est une activité entièrement différente dans un système ocap que dans un système ACL. Cette réflexion s'étend à l'architecture fondamentale des applications elles-mêmes, ainsi qu'à celle d'éléments tels que les langages de programmation, les cadres d'application, les protocoles réseau et les systèmes d'exploitation.

Capability patterns To give you a taste of what I mean by affecting fundamental architecture, let’s fulfill the promise I made earlier to talk about how we address some of the concerns that someone from a more traditional ACL background might have.		Modèles de capacités Pour vous donner un avant-goût de ce que je veux dire en affectant l'architecture fondamentale, remplissons la promesse que j'ai faite plus tôt de parler de la façon dont nous répondons à certaines des préoccupations que pourrait avoir une personne issue d'un contexte ACL plus traditionnel.

The ocap approach both enables and relies on compositionality – putting things together in different ways to make new kinds of things. This isn’t really part of the ACL toolbox at all. The word “compositionality” is kind of vague, so I’ll illustrate what I’m talking about with some specific capability patterns. For discussion purposes, I’m going to group these patterns into a few rough categories: modulation, attenuation, abstraction, and combination. Note that there’s nothing fundamental about these, they’re just useful for presentation.		L'approche ocap permet et repose à la fois sur la compositionnalité - assembler les choses de différentes manières pour créer de nouveaux types de choses. Cela ne fait pas vraiment partie de la boîte à outils ACL. Le mot «compositionnalité» est un peu vague, je vais donc illustrer ce dont je parle avec quelques modèles de capacités spécifiques. À des fins de discussion, je vais regrouper ces modèles en quelques catégories approximatives: modulation, atténuation, abstraction et combinaison. Notez qu'il n'y a rien de fondamental à ce sujet, ils sont juste utiles pour la présentation.

Modulation[edit]		Modulation[ modifier ]

By modulation, I mean having one object modulate access to another. The most important example of this is called a revoker. A major source of the anxiety that some people from an ACL background have about capabilities is the feeling that a capability can easily escape their control. If I’ve given someone access to some resource, what happens if later I decide it’s inappropriate for them to have it? In the ACL model, the answer appears to be simple: I merely remove that person’s entry from the resource’s ACL. In the ocap model, if I’ve given them one of my capabilities, then now they have it too, so what can I do if I don’t want them to have it any more? The answer is that I didn’t give them my capability. Instead I gave them a new capability that I created, a reference to an intermediate object that holds my capability but remains controlled by me in a way that lets me disable it later. We call such a thing a revoker, because it can revoke access. A rudimentary form of this is just a simple message forwarder that can be commanded to drop its forwarding pointer.		Par modulation, j'entends avoir un objet moduler l'accès à un autre. L'exemple le plus important de ceci s'appelle un révocateur. Une source majeure de l'anxiété que certaines personnes issues de l'ACL ont à propos des capacités est le sentiment qu'une capacité peut facilement échapper à leur contrôle. Si j'ai donné à quelqu'un l'accès à une ressource, que se passe-t-il si plus tard je décide qu'il n'est pas approprié pour lui de l'avoir? Dans le modèle ACL, la réponse semble simple: je supprime simplement l'entrée de cette personne de l'ACL de la ressource. Dans le modèle ocap, si je leur ai donné l'une de mes capacités, alors maintenant ils l'ont aussi, alors que puis-je faire si je ne veux plus qu'ils l'aient? La réponse est que je ne leur ai pas donné mes capacités. Au lieu de cela, je leur ai donné une nouvelle capacité que j'ai créée, une référence à un objet intermédiaire qui détient ma capacité mais reste contrôlé par moi d'une manière qui me permet de le désactiver plus tard. Nous appelons une telle chose un révocateur, car cela peut révoquer l'accès. Une forme rudimentaire de ceci est juste un simple transmetteur de message qui peut être commandé pour abandonner son pointeur de transfert.

Modulation can be more sophisticated than simple revocation. For example, I could provide someone with a capability that I can switch on or off at will. I could make access conditional on time or date or location. I could put controls on the frequency or quantity of use (a use-once capability with a built-in expiration date might be particularly useful). I could even make an intermediary object that requires payment in exchange for access. The possibilities are limited only by need and imagination.		La modulation peut être plus sophistiquée qu'une simple révocation. Par exemple, je pourrais fournir à quelqu'un une capacité que je peux activer ou désactiver à volonté. Je pourrais rendre l'accès conditionnel à l'heure, à la date ou au lieu. Je pourrais mettre des contrôles sur la fréquence ou la quantité d'utilisation (une capacité d'utilisation unique avec une date d'expiration intégrée pourrait être particulièrement utile). Je pourrais même faire un objet intermédiaire qui nécessite un paiement en échange d'un accès. Les possibilités ne sont limitées que par le besoin et l'imagination.

The revoker pattern solves the problem of taking away access, but what about controlling delegation? Capabilities are essentially bearer instruments – they convey their authority to whoever holds them, without regard to who the holder is. This means that if I give someone a capability, they could pass it to someone else whose access I don’t approve of. This is another big source of anxiety for people in the ACL camp: the idea that in the capability model there’s no way to know who has access. This is not rooted in some misunderstanding of capabilities either; it’s actually true. But the ACL model doesn’t really help with this, because it has the same problem.		Le modèle de révocateur résout le problème de la suppression de l'accès, mais qu'en est-il du contrôle de la délégation? Les capacités sont essentiellement des instruments porteurs - elles transmettent leur autorité à quiconque les détient, sans égard à qui en est le détenteur. Cela signifie que si je donne une capacité à quelqu'un, il pourrait la transmettre à quelqu'un d'autre dont je n'approuve pas l'accès. C'est une autre grande source d'anxiété pour les personnes du camp ACL: l'idée que dans le modèle de capacité, il n'y a aucun moyen de savoir qui a accès. Cela ne tient pas non plus à une incompréhension des capacités; c'est en fait vrai. Mais le modèle ACL n'aide pas vraiment avec cela, car il a le même problème.

In real world use cases, the need to share resources and to delegate access is very common. Since the ACL model provides no mechanism for this, people fall back on sharing credentials, often in the face of corporate policies or terms of use that specifically forbid this. When presented with the choice between following the rules and getting their job done, people will often pick the latter. Consider, for example, how common it is for a secretary or executive assistant to know their boss’s password – in my experience, it’s almost universal.		Dans des cas d'utilisation réels, le besoin de partager des ressources et de déléguer l'accès est très courant. Étant donné que le modèle ACL ne fournit aucun mécanisme pour cela, les gens recourent au partage des informations d'identification, souvent face à des politiques d'entreprise ou à des conditions d'utilisation qui l'interdisent spécifiquement. Lorsqu'on leur présente le choix entre suivre les règles et faire leur travail, les gens choisissent souvent ce dernier. Considérez, par exemple, à quel point il est courant pour une secrétaire ou une adjointe de direction de connaître le mot de passe de leur patron - d'après mon expérience, c'est presque universel.

There’s a widespread belief that an ACL tells you who has access, but this is just an illusion, due to the fact that credential sharing is invisible to the access control system. What you really have is something that tells you who to hold responsible if a resource is used inappropriately. And if you think about it, this is what you actually want anyway. The ocap model also supports this type of accountability, but can do a much better job of it.		Il y a une croyance répandue qu'une ACL vous dit qui a accès, mais ce n'est qu'une illusion, car le partage des informations d'identification est invisible pour le système de contrôle d'accès. Ce que vous avez vraiment, c'est quelque chose qui vous indique qui vous devez tenir responsable si une ressource est utilisée de manière inappropriée. Et si vous y réfléchissez, c'est ce que vous voulez vraiment de toute façon. Le modèle ocap prend également en charge ce type de responsabilité, mais peut faire un bien meilleur travail.

The first problem with credential sharing is that it’s far too permissive. If my boss gives me their company LDAP password so I can access their calendar and email, they’re also giving me access to everything else that’s protected by that password, which might extend to things like sensitive financial or personnel records, or even the power to spend money from the company bank account. Capabilities, in contrast, allow them to selectively grant me access to specific things.		Le premier problème avec le partage des informations d'identification est qu'il est beaucoup trop permissif. Si mon patron me donne le mot de passe LDAP de son entreprise pour que je puisse accéder à son calendrier et à sa messagerie électronique, il me donne également accès à tout ce qui est protégé par ce mot de passe, ce qui peut s'étendre à des choses comme les dossiers financiers ou personnels sensibles, ou même le pouvoir pour dépenser de l'argent sur le compte bancaire de l'entreprise. Les capacités, en revanche, leur permettent de m'accorder sélectivement l'accès à des choses spécifiques.

The second problem with credential sharing is that if I use my access inappropriately, there’s no way to distinguish my accesses from theirs. It’s hard for my boss to claim “my flunky did it!” if the activity logs are tied to the boss’s name, especially if they weren’t supposed to have shared the credentials in the first place. And of course this risk applies in the other direction as well: if it’s an open secret that I have my boss’s password, suspicion for their misbehavior can fall on me; indeed, if my boss was malicious they might share credentials just to gain plausible deniability when they abscond with company assets. The revoker pattern, however, can be extended to enable delegation to be auditable. I delegate by passing someone an intermediary object that takes note of who is being delegated to and why, and then it can record this information in an audit log when it is used. Now, if the resource is misused, we actually know who to blame.		Le deuxième problème avec le partage d'informations d'identification est que si j'utilise mon accès de manière inappropriée, il n'y a aucun moyen de distinguer mes accès des leurs. Il est difficile pour mon patron de prétendre que "mon pervers l'a fait!" si les journaux d'activité sont liés au nom du patron, surtout s'ils n'étaient pas censés avoir partagé les informations d'identification en premier lieu. Et bien sûr, ce risque s'applique également dans l'autre sens: si c'est un secret de polichinelle que j'ai le mot de passe de mon patron, la suspicion pour leur mauvaise conduite peut tomber sur moi; en effet, si mon patron était malveillant, il pourrait partager ses informations d'identification juste pour obtenir un déni plausible lorsqu'il s'enfuit avec les actifs de l'entreprise. Le modèle de révocateur, cependant, peut être étendu pour permettre à la délégation d'être auditable. Je délègue en passant à quelqu'un un objet intermédiaire qui prend note de qui est délégué et pourquoi, puis il peut enregistrer ces informations dans un journal d'audit lorsqu'il est utilisé. Maintenant, si la ressource est mal utilisée, nous savons réellement qui blâmer.

Keep in mind also that credential sharing isn’t limited to shared passwords. For example, if somebody asks me to run a program for them, then whatever it is that they wanted done by that program gets done using my credentials. Even if what the program did was benign and the request was made with the best of intentions, we’ve still lost track of who was responsible. This is the reason why some companies forbid running software they haven’t approved on company computers.		Gardez également à l'esprit que le partage d'informations d'identification ne se limite pas aux mots de passe partagés. Par exemple, si quelqu'un me demande d'exécuter un programme pour lui, alors tout ce qu'il voulait faire par ce programme est fait en utilisant mes informations d'identification. Même si ce que le programme a fait était bénin et que la demande a été faite avec les meilleures intentions du monde, nous avons quand même perdu la trace de qui était responsable. C'est la raison pour laquelle certaines entreprises interdisent d'exécuter des logiciels qu'elles n'ont pas approuvés sur les ordinateurs de l'entreprise.

Attenuation[edit]		Atténuation[ modifier ]

When I talk about attenuation, I mean reducing what a capability lets you do – its scope of authority. The scope of authority can encompass both the operations that are enabled and the range of resources that can be accessed. The later is particularly important, because it’s quite common for methods on an object’s API to return references to other objects as a result (once again, a concept that is foreign to the ACL world). For example, one might have a capability that gives access to a computer’s file system. Using this, an attenuator object might instead provide access only to a specific file, or perhaps to some discrete sub-directory tree in a file hierarchy (i.e., a less clumsy version of what the Unix chroot operation does).		Quand je parle d'atténuation, je veux dire de réduire ce qu'une capacité vous permet de faire - sa portée d'autorité. L'étendue de l'autorité peut englober à la fois les opérations activées et la gamme de ressources accessibles. Ce dernier est particulièrement important, car il est assez courant pour les méthodes de l'API d'un objet de renvoyer des références à d'autres objets (encore une fois, un concept étranger au monde ACL). Par exemple, on pourrait avoir une capacité qui donne accès au système de fichiers d'un ordinateur. En utilisant cela, un objet atténuateur pourrait à la place fournir un accès uniquement à un fichier spécifique, ou peut-être à une arborescence de sous-répertoires discrète dans une hiérarchie de fichiers (c'est-à-dire une version moins maladroite de ce que fait l'opération chroot Unix).

Attenuating functionality is also possible. For example, the base capability to a file might allow any operation the underlying file system supports: read, write, append, delete, truncate, etc. From this you can readily produce a read-only capability to the same file: simply have the intermediary object support read requests without providing any other file API methods.		Une fonctionnalité d'atténuation est également possible. Par exemple, la capacité de base d'un fichier peut permettre toute opération prise en charge par le système de fichiers sous-jacent: lire, écrire, ajouter, supprimer, tronquer, etc. À partir de là, vous pouvez facilement produire une capacité en lecture seule sur le même fichier: Les objets intermédiaires prennent en charge les demandes de lecture sans fournir aucune autre méthode API de fichier.

Of course, these are composable: one could readily produce a read-only capability to a particular file from a capability providing unlimited access to an entire file system. Attenuators are particularly useful for packaging access to the existing, non-capability oriented world into capabilities. In addition to the hierarchical file system wrapper just described, attenuators are helpful for mediating access to network communications (for example, limiting connections to particular domains, allowing applications to be securely distributed across datacenters without also enabling them talk to arbitrary hosts on the internet – the sort of thing that would normally be regulated by firewall configuration, but without the operational overhead or administrative inconvenience). Another use would be controlling access to specific portions of the rendering surface of a display device, something that many window systems already do in an almost capability-like fashion anyway.		Bien sûr, ceux-ci sont composables: on pourrait facilement produire une capacité en lecture seule pour un fichier particulier à partir d'une capacité offrant un accès illimité à tout un système de fichiers. Les atténuateurs sont particulièrement utiles pour regrouper l'accès au monde existant non axé sur les capacités en capacités. En plus de l'encapsuleur de système de fichiers hiérarchique qui vient d'être décrit, les atténuateurs sont utiles pour médier l'accès aux communications réseau (par exemple, limiter les connexions à des domaines particuliers, permettant aux applications d'être distribuées en toute sécurité dans les centres de données sans leur permettre également de parler à des hôtes arbitraires sur Internet - le genre de chose qui serait normalement régulée par la configuration du pare-feu, mais sans les frais généraux opérationnels ou les inconvénients administratifs).

Abstraction[edit]		Abstraction[ modifier ]

Abstraction enters the picture because once we have narrowed what authority a given capability represents, it often makes sense to refactor what it does into something with a more appropriately narrow set of affordances. For example, it might make sense to package the read-only file capability mentioned above into an input stream object, rather than something that represents a file per se. At this point you might ask if this is really any different from ordinary good object oriented programming practice. The short answer is, it’s not – capabilities and OOP are strongly aligned, as I’ve mentioned several times already. A somewhat longer answer is that the capability perspective usefully shapes how you design interfaces.		L'abstraction entre en jeu parce qu'une fois que nous avons réduit l'autorité qu'une capacité donnée représente, il est souvent logique de refactoriser ce qu'elle fait en quelque chose avec un ensemble plus approprié d'affordances. Par exemple, il peut être judicieux de regrouper la capacité de fichier en lecture seule mentionnée ci-dessus dans un objet de flux d'entrée, plutôt que quelque chose qui représente un fichier en soi. À ce stade, vous pourriez vous demander si cela est vraiment différent des bonnes pratiques de programmation orientées objet ordinaires. La réponse courte est que ce n'est pas le cas - les capacités et la POO sont fortement alignées, comme je l'ai déjà mentionné à plusieurs reprises. Une réponse un peu plus longue est que la perspective des capacités façonne utilement la façon dont vous concevez les interfaces.

A core idea that capability enthusiasts use heavily is the Principle of Least Authority (abbreviated POLA, happily pronounceable). The principle states that objects should be given only the specific authority necessary to do their jobs, and no more. The idea is that the fewer things an object can do, the less harm can result if it misbehaves or if its integrity is breached.		Une idée centrale que les amateurs de capacités utilisent beaucoup est le principe de la moindre autorité (en abrégé POLA, heureusement prononçable). Le principe stipule que les objets ne devraient recevoir que l'autorité spécifique nécessaire pour faire leur travail, et rien de plus. L'idée est que moins un objet peut faire de choses, moins il peut en résulter de dommages s'il se comporte mal ou si son intégrité est violée.

Least Authority is related to the notions of Least Privilege or Least Permission that you’ll frequently see in a lot of the traditional (non-capability) security literature. In part, this difference in jargon is just a cultural marker that separates the two camps. Often the traditional literature will tell you that authority and permission and privilege all mean more or less the same thing.		La moindre autorité est liée aux notions de moindre privilège ou de moindre autorisation que vous verrez fréquemment dans une grande partie de la littérature sur la sécurité traditionnelle (sans capacité). En partie, cette différence de jargon n'est qu'un marqueur culturel qui sépare les deux camps. Souvent, la littérature traditionnelle vous dira que l'autorité, la permission et le privilège signifient plus ou moins la même chose.

However, we really do prefer to talk about “authority”, which we take to represent the full scope of what someone or something is able to do, whereas “permission” refers to a particular set of access settings. For example, on a Unix system I typically don’t have permission to modify the /etc/passwd file, but I do typically have permission to execute the passwd command, which does have permission to modify the file. This command will make selected changes to the file on my behalf, thus giving me the authority to change my password. We also think of authority in terms of what you can actually do. To continue the example of the passwd command, it has permission to delete the password file entirely, but it does not make this available to me, thus it does not convey that authority to me even though it could if it were programmed to do so.		Cependant, nous préférons vraiment parler d '«autorité», que nous considérons comme représentant toute l'étendue de ce que quelqu'un ou quelque chose est capable de faire, alors que «permission» fait référence à un ensemble particulier de paramètres d'accès. Par exemple, sur un système Unix, je n'ai généralement pas l'autorisation de modifier le fichier / etc / passwd, mais j'ai généralement l'autorisation d'exécuter la commande passwd, qui a l'autorisation de modifier le fichier. Cette commande apportera des modifications sélectionnées au fichier en mon nom, me donnant ainsi le droit de modifier mon mot de passe. Nous pensons également à l'autorité en termes de ce que vous pouvez réellement faire. Pour continuer l'exemple de la commande passwd, il a la permission de supprimer entièrement le fichier de mot de passe, mais il ne le met pas à ma disposition, donc il ne me transmet pas cette autorité même s'il le pouvait s'il était programmé pour le faire.

The passwd command is an example of abstracting away the low level details of file access and data formats, instead repackaging them into a more specific set of operations that is more directly meaningful to its user. This kind of functionality refactoring is very natural from a programming perspective, but using it to also refactor access is awkward in the ACL case. ACL systems typically have to leverage slippery abstractions like the Unix setuid mechanism. Setuid is what makes the Unix passwd command possible in the first place, but it’s a potent source of confused deputy problems that’s difficult to use safely; an astonishing number of Unix security exploits over the years have involved setuid missteps. The ocap approach avoids these missteps because the appropriate reduction in authority often comes for free as a natural consequence of the straightforward implementation of the operation being provided.		La commande passwd est un exemple d'abstraction des détails de bas niveau d'accès aux fichiers et de formats de données, en les reconditionnant à la place dans un ensemble d'opérations plus spécifique qui est plus directement significatif pour son utilisateur. Ce type de refactoring de fonctionnalités est très naturel du point de vue de la programmation, mais son utilisation pour refactoriser également l'accès est gênant dans le cas de l'ACL. Les systèmes ACL doivent généralement tirer parti d'abstractions glissantes comme le mécanisme setuid d'Unix. Setuid est ce qui rend la commande passwd Unix possible en premier lieu, mais c'est une source puissante de problèmes d'adjoint confus qui sont difficiles à utiliser en toute sécurité; un nombre étonnant d'exploits de sécurité Unix au fil des ans ont impliqué des faux pas de setuid.

Combination[edit]		Combinaison[ modifier ]

When I talk about combination, I mean using two or more capabilities together to create a new capability to some specific joint functionality. In some cases, this is simply the intersection of two different authorities. However, the more interesting cases are when we put things together to create something truly new.		Quand je parle de combinaison, je veux dire utiliser deux capacités ou plus ensemble pour créer une nouvelle capacité pour une fonctionnalité conjointe spécifique. Dans certains cas, il s'agit simplement de l'intersection de deux autorités différentes. Cependant, les cas les plus intéressants sont ceux où nous mettons les choses ensemble pour créer quelque chose de vraiment nouveau.

For example, imagine a smartphone running a capability oriented operating system instead of iOS or Android. The hardware features of such a phone would, of course, be accessed via capabilities, which the OS would hand out to applications according to configuration rules or user input. So we could imagine combining three important capabilities: the authority to capture images using the camera, the authority to obtain the device’s geographic position via its built-in GPS receiver, and the authority to read the system clock. These could be encapsulated inside an object, along with a (possibly manufacturer provided) private cryptographic key, yielding a new capability that when invoked provides signed, authenticated, time stamped, geo-referenced images from the camera. This capability could then be granted to applications that require high integrity imaging, like police body cameras, automobile dash cams, journalistic apps, and so on. If this capability is the only way for such applications to get access to the camera at all, then the applications’ developers don’t have to be trusted to maintain a secure chain of evidence for the imagery. This both simplifies their implementation task – they can focus their efforts on their applications’ unique needs instead of fiddling with signatures and image formats – and makes their output far more trustworthy, since they don’t have prove their application code doesn’t tamper with the data (you still have to trust the phone and the OS, but that’s at least a separable problem).		Par exemple, imaginez un smartphone exécutant un système d'exploitation orienté capacités au lieu d'iOS ou d'Android. Les fonctionnalités matérielles d'un tel téléphone seraient bien entendu accessibles via des fonctionnalités que le système d'exploitation distribuerait aux applications en fonction des règles de configuration ou des entrées de l'utilisateur. Nous pourrions donc imaginer combiner trois capacités importantes: l'autorité de capturer des images à l'aide de la caméra, l'autorité d'obtenir la position géographique de l'appareil via son récepteur GPS intégré et l'autorité de lire l'horloge du système. Celles-ci pourraient être encapsulées dans un objet, avec une clé cryptographique privée (éventuellement fournie par le fabricant), donnant une nouvelle capacité qui, lorsqu'elle est invoquée, fournit des images signées, authentifiées, horodatées et géo-référencées de la caméra. Cette capacité pourrait ensuite être accordée aux applications qui nécessitent une imagerie à haute intégrité, comme les caméras de police, les caméras de tableau de bord automobiles, les applications journalistiques, etc. Si cette capacité est le seul moyen pour de telles applications d'accéder à la caméra, il n'est pas nécessaire de faire confiance aux développeurs d'applications pour maintenir une chaîne de preuves sécurisée pour les images. Cela simplifie à la fois leur tâche de mise en œuvre - ils peuvent concentrer leurs efforts sur les besoins uniques de leurs applications au lieu de jouer avec les signatures et les formats d'image - et rend leur sortie beaucoup plus fiable, car ils n'ont pas prouvé que le code de leur application ne falsifie pas. les données (vous devez toujours faire confiance au téléphone et au système d'exploitation, mais c'est au moins un problème séparable). Si cette capacité est le seul moyen pour de telles applications d'accéder à la caméra, il n'est pas nécessaire de faire confiance aux développeurs d'applications pour maintenir une chaîne de preuves sécurisée pour les images. Cela simplifie à la fois leur tâche de mise en œuvre - ils peuvent concentrer leurs efforts sur les besoins uniques de leurs applications au lieu de jouer avec les signatures et les formats d'image - et rend leur sortie beaucoup plus fiable, car ils n'ont pas prouvé que le code de leur application ne falsifie pas. les données (vous devez toujours faire confiance au téléphone et au système d'exploitation, mais c'est au moins un problème séparable). Si cette capacité est le seul moyen pour de telles applications d'accéder à la caméra, il n'est pas nécessaire de faire confiance aux développeurs d'applications pour maintenir une chaîne de preuves sécurisée pour les images. Cela simplifie à la fois leur tâche de mise en œuvre - ils peuvent concentrer leurs efforts sur les besoins uniques de leurs applications au lieu de jouer avec les signatures et les formats d'image - et rend leur sortie beaucoup plus fiable, car ils n'ont pas prouvé que le code de leur application ne falsifie pas. les données (vous devez toujours faire confiance au téléphone et au système d'exploitation, mais c'est au moins un problème séparable).

What can we do with this? I’ve talked at length about the virtues of the capability approach, but at the same time observed repeatedly (if only in criticism) that this is not how most contemporary systems work. So even if these ideas are as virtuous as I maintain they are, we’re still left with the question of what use we can make of them absent some counterfactual universe of technical wonderfulness.		Que pouvons-nous faire avec ça? J'ai longuement parlé des vertus de l'approche capacitaire, mais j'ai en même temps observé à plusieurs reprises (ne serait-ce que dans la critique) que ce n'est pas ainsi que fonctionnent la plupart des systèmes contemporains. Donc, même si ces idées sont aussi vertueuses que je le maintiens, nous nous retrouvons toujours avec la question de l'utilisation que nous pouvons en faire en l'absence d'un univers contrefactuel de merveille technique.

There are several ways these ideas can provide direct value without first demanding that we replace the entire installed base of software that makes the world go. This is not to say that the installed base never gets replaced, but it’s a gradual, incremental process. It’s driven by small, local changes rather than by the unfolding of some kind of authoritative master plan. So here are a few incremental ways to apply these ideas to the current world. My hope is that these can deliver enough immediate value to bias practitioners in a positive direction, shaping the incentive landscape so it tilts towards a less dysfunctional software ecosystem. Four areas in particular seem salient to me in this regard: embedded systems, compartmentalized computation, distributed services, and software engineering practices.		Ces idées peuvent apporter une valeur directe de plusieurs façons sans exiger au préalable que nous remplacions toute la base de logiciels installée qui fait tourner le monde. Cela ne veut pas dire que la base installée n'est jamais remplacée, mais c'est un processus progressif et incrémentiel. Il est motivé par de petits changements locaux plutôt que par le déploiement d'une sorte de plan directeur faisant autorité. Voici donc quelques moyens supplémentaires d'appliquer ces idées au monde actuel. Mon espoir est que ceux-ci peuvent offrir une valeur immédiate suffisante pour orienter les praticiens dans une direction positive, façonnant le paysage des incitations afin qu'il s'incline vers un écosystème logiciel moins dysfonctionnel. Quatre domaines me paraissent en particulier saillants à cet égard: les systèmes embarqués, le calcul compartimenté, les services distribués et les pratiques de génie logiciel.

Embedded systems[edit]		Systèmes embarqués[ modifier ]

Capability principles are a very good way to organize an operating system. Two of the most noteworthy examples, in my opinion, are KeyKOS and seL4.		Les principes de capacité sont un très bon moyen d'organiser un système d'exploitation. Deux des exemples les plus remarquables, à mon avis, sont KeyKOS et seL4.

KeyKOS was developed in the 1980s for IBM mainframes by Key Logic, a spinoff from Tymshare. In addition to being a fully capability secure OS, it attained extraordinarily high reliability via an amazing, high performance orthogonal persistence mechanism that allowed processes to run indefinitely, surviving things like loss of power or hardware failure. Some commercial KeyKOS installations had processes that ran for years, in a few cases even spanning replacement of the underlying computer on which they were running. Towards the end of its commercial life, KeyKOS was also ported to several other processor architectures, making it a potentially interesting jumping off point for further development. KeyKOS has inspired a number of follow ons, including Eros, CapROS, and Coyotos. Unfortunately most of these efforts have been significantly resource starved and consequently have not yet had much real world impact. But the code for KeyKOS and its descendants is out there for the taking if anybody wants to give it a go.		KeyKOS a été développé dans les années 1980 pour les mainframes IBM par Key Logic, une spin-off de Tymshare. En plus d'être un système d'exploitation entièrement sécurisé, il a atteint une fiabilité extrêmement élevée grâce à un mécanisme de persistance orthogonale étonnamment performant qui permettait aux processus de s'exécuter indéfiniment, survivant à des problèmes tels qu'une perte d'alimentation ou une panne matérielle. Certaines installations commerciales KeyKOS avaient des processus qui ont duré des années, dans certains cas, même le remplacement de l'ordinateur sous-jacent sur lequel ils fonctionnaient. Vers la fin de sa vie commerciale, KeyKOS a également été porté sur plusieurs autres architectures de processeurs, ce qui en fait un point de départ potentiellement intéressant pour un développement ultérieur. KeyKOS a inspiré un certain nombre de suivis, notamment Eros, CapROS et Coyotos. Malheureusement, la plupart de ces efforts ont été considérablement privés de ressources et n'ont donc pas encore eu beaucoup d'impact sur le monde réel. Mais le code pour KeyKOS et ses descendants est là pour la prise si quelqu'un veut l'essayer.

seL4 is a secure variant of the L4 operating system, developed by NICTA in Australia. While building on the earlier L3 and L4 microkernels, seL4 is a from scratch design heavily influenced by KeyKOS. seL4 notably has a formal proof of functional correctness, making it an extremely sound basis for building secure and reliable systems. It’s starting to make promising inroads into applications that demand this kind of assurance, such as military avionics. Like KeyKOS, seL4, as well as seL4’s associated suite of proofs, is available as open source software.		seL4 est une variante sécurisée du système d'exploitation L4, développé par NICTA en Australie. Tout en s'appuyant sur les micro-noyaux L3 et L4 antérieurs, seL4 est une conception à partir de zéro fortement influencée par KeyKOS. seL4 dispose notamment d'une preuve formelle d'exactitude fonctionnelle, ce qui en fait une base extrêmement solide pour construire des systèmes sûrs et fiables. Il commence à faire des incursions prometteuses dans des applications qui exigent ce type d'assurance, comme l'avionique militaire. Comme KeyKOS, seL4, ainsi que la suite de preuves associée à seL4, est disponible en tant que logiciel open source.

Embedded systems, including much of the so called “Internet of Things”, are sometimes less constrained by installed base issues on account of being standalone products with narrow functionality, rather than general purpose computational systems. They often have fewer points where legacy interoperability is as important. Moreover, they’re usually cross-developed with tools that already expect the development and runtime environments to be completely different, allowing them to be bootstrapped via legacy toolchains. In other words, you don’t have to port your entire development system to the new OS in order to take advantage of it, but rather can continue using most of your existing tools and workflow processes. This is certainly true of the capability OS efforts I just mentioned, which have all dealt with these issues.		Les systèmes embarqués, y compris une grande partie du soi-disant «Internet des objets», sont parfois moins limités par des problèmes de base installée en raison du fait qu'ils sont des produits autonomes avec des fonctionnalités étroites, plutôt que des systèmes de calcul à usage général. Ils ont souvent moins de points où l'interopérabilité héritée est aussi importante. De plus, ils sont généralement développés de manière croisée avec des outils qui s'attendent déjà à ce que les environnements de développement et d'exécution soient complètement différents, ce qui leur permet d'être amorcés via des chaînes d'outils héritées. En d'autres termes, vous n'avez pas à porter l'intégralité de votre système de développement vers le nouveau système d'exploitation pour en profiter, mais vous pouvez plutôt continuer à utiliser la plupart de vos outils et processus de flux de travail existants. Cela est certainement vrai des efforts de capacité OS que je viens de mentionner, qui ont tous traité de ces problèmes.

Furthermore, embedded software is often found in mission critical systems that must function reliably in a high threat environment. In these applications, reliability and security can take priority over cost minimization, making the assurances that a capability OS can offer comparatively more attractive. Consequently, using one of these operating systems as the basis for a new embedded application platform seems like an opportunity, particularly in areas where reliability is important.		De plus, les logiciels embarqués se trouvent souvent dans les systèmes critiques qui doivent fonctionner de manière fiable dans un environnement à haut risque. Dans ces applications, la fiabilité et la sécurité peuvent avoir la priorité sur la minimisation des coûts, ce qui donne l'assurance qu'un système d'exploitation de capacités peut offrir comparativement plus attrayant. Par conséquent, utiliser l'un de ces systèmes d'exploitation comme base d'une nouvelle plateforme applicative embarquée apparaît comme une opportunité, notamment dans les domaines où la fiabilité est importante.

A number of recent security incidents on the internet have revolved around compromised IoT devices. A big part of the problem is that the application code in these products typically has complete access to everything in the device, largely as a convenience to the developers. This massive violation of least privilege then makes these devices highly vulnerable to exploitation when an attacker finds flaws in the application code.		Un certain nombre d'incidents de sécurité récents sur Internet ont tourné autour d'appareils IoT compromis. Une grande partie du problème est que le code d'application de ces produits a généralement un accès complet à tout ce qui se trouve dans l'appareil, en grande partie pour la commodité des développeurs. Cette violation massive du moindre privilège rend alors ces appareils très vulnérables à l'exploitation lorsqu'un attaquant découvre des failles dans le code de l'application.

Rigorously compartmentalizing available functionality would greatly reduce the chances of these kinds of vulnerabilities, but this usually doesn’t happen. Partly this is just ignorance – most of these developers are not generally also security experts, especially when the things they are working on are not, on their face, security sensitive applications. However, I think a bigger issue is that the effort and inconvenience involved in building a secure system with current building blocks doesn’t seem justified by the payoff.		Le compartimentage rigoureux des fonctionnalités disponibles réduirait considérablement les risques de ce type de vulnérabilités, mais cela ne se produit généralement pas. C'est en partie de l'ignorance - la plupart de ces développeurs ne sont généralement pas également des experts en sécurité, en particulier lorsque les choses sur lesquelles ils travaillent ne sont pas, à première vue, des applications sensibles à la sécurité. Cependant, je pense qu'un problème plus important est que l'effort et les inconvénients impliqués dans la construction d'un système sécurisé avec les éléments de base actuels ne semblent pas justifiés par le gain.

No doubt the developers of these products would prefer to produce more secure systems than they often do, all other things being equal, but all other things are rarely equal. One way to tilt the balance in our favor would be to give them a platform that more or less automatically delivers desirable security and reliability properties as a consequence of developers simply following the path of least resistance. This is the payoff that building on top of a capability OS offers.		Nul doute que les développeurs de ces produits préféreraient produire des systèmes plus sécurisés qu'ils ne le font souvent, toutes choses étant égales par ailleurs, mais toutes les autres choses sont rarement égales. Une façon de faire pencher la balance en notre faveur serait de leur donner une plate-forme qui offre plus ou moins automatiquement les propriétés de sécurité et de fiabilité souhaitables, car les développeurs suivent simplement le chemin de la moindre résistance. C'est le gain qu'offre la construction au-dessus d'un système d'exploitation de capacité.

Compartmentalized computation[edit]		Calcul compartimenté[ modifier ]

Norm Hardy – one of the primary architects of KeyKOS, who I’ve already mentioned several times – has quipped that “the last piece of software anyone ever writes for a secure, capability OS is always the Unix virtualization layer.” This is a depressing testimony to the power that the installed base has over the software ecosystem. However, it also suggests an important benefit that these kinds of OS’s can provide, even in an era when Linux is the defacto standard.		Norm Hardy - l'un des principaux architectes de KeyKOS, que j'ai déjà mentionné à plusieurs reprises - a plaisanté en disant que «le dernier logiciel que quelqu'un ait jamais écrit pour un système d'exploitation sécurisé et fonctionnel est toujours la couche de virtualisation Unix.» C'est un témoignage déprimant de la puissance de la base installée sur l'écosystème logiciel. Cependant, cela suggère également un avantage important que ces types de systèmes d'exploitation peuvent offrir, même à une époque où Linux est le standard de facto.

In the new world of cloud computing, virtualization is increasingly how everything gets done. Safety-through-compartmentalization has long been one of the key selling points driving this trend. The idea is that even if an individual VM is compromised due to an exploitable flaw in the particular mix of application code, libraries, and OS services that it happens to be running, this does not gain the attacker access to other, adjacent VMs running on the same hardware.		Dans le nouveau monde du cloud computing, la virtualisation est de plus en plus la façon dont tout est fait. Le compartimentage de la sécurité a longtemps été l'un des principaux arguments de vente à l'origine de cette tendance. L'idée est que même si une VM individuelle est compromise en raison d'une faille exploitable dans le mélange particulier de code d'application, de bibliothèques et de services de système d'exploitation qu'elle exécute, cela ne permet pas à l'attaquant d'accéder à d'autres VM adjacentes s'exécutant sur le même matériel.

The underlying idea – isolate independent pieces of computation so they can’t interfere with each other – is not new. It is to computer science what vision is to evolutionary biology, an immensely useful trick that gets reinvented over and over again in different contexts. In particular, it’s a key idea motivating the architecture of most multitasking operating systems in the first place. Process isolation has long been the standard way for keeping one application from messing up another. What virtualization brings to the table is to give application and service operators control over a raft of version and configuration management issues that were traditionally out of their hands, typically in the domain of the operators of the underlying systems on which they were running. Thus, for example, even if everyone in your company is using Linux it could still be the case that a service you manage depends on some Apache module that only works on Linux version X, while another some other wing of your company has a service requiring a version of MySQL that only works with Linux version Y. But with virtualization you don’t need to fight about which version of Linux to run on your company server machines. Instead, you can each have your own VMs running whichever version you need. More significantly, even if the virtualization system itself requires Linux version Z, it’s still not a problem, because it’s at a different layer of abstraction.		L'idée sous-jacente - isoler des éléments de calcul indépendants pour qu'ils ne puissent pas interférer les uns avec les autres - n'est pas nouvelle. C'est à l'informatique ce que la vision est à la biologie évolutionniste, une astuce immensément utile qui se réinvente encore et encore dans différents contextes. En particulier, c'est une idée clé qui motive l'architecture de la plupart des systèmes d'exploitation multitâches en premier lieu. L'isolement des processus a longtemps été le moyen standard pour empêcher une application d'en gâcher une autre. Ce que la virtualisation apporte à la table est de donner aux opérateurs d'applications et de services le contrôle sur une série de problèmes de gestion de version et de configuration qui étaient traditionnellement hors de leurs mains, généralement dans le domaine des opérateurs des systèmes sous-jacents sur lesquels ils s'exécutaient. Ainsi, par exemple, même si tout le monde dans votre entreprise utilise Linux, il se peut qu'un service que vous gérez dépende d'un module Apache qui ne fonctionne que sur la version X de Linux, tandis qu'une autre autre aile de votre entreprise a un service nécessitant une version de MySQL qui ne fonctionne qu'avec la version Y de Linux. Mais avec la virtualisation, vous n'avez pas besoin de vous demander quelle version de Linux exécuter sur les serveurs de votre entreprise. Au lieu de cela, vous pouvez chacun avoir vos propres machines virtuelles exécutant la version dont vous avez besoin. Plus important encore, même si le système de virtualisation lui-même nécessite la version Z de Linux, ce n'est toujours pas un problème, car il se situe à un niveau d'abstraction différent. tandis qu'une autre autre aile de votre entreprise a un service nécessitant une version de MySQL qui ne fonctionne qu'avec la version Y de Linux. Mais avec la virtualisation, vous n'avez pas besoin de vous battre pour savoir quelle version de Linux exécuter sur les machines serveur de votre entreprise. Au lieu de cela, vous pouvez chacun avoir vos propres machines virtuelles exécutant la version dont vous avez besoin. Plus important encore, même si le système de virtualisation lui-même nécessite la version Z de Linux, ce n'est toujours pas un problème, car il se situe à un niveau d'abstraction différent. tandis qu'une autre autre aile de votre entreprise a un service nécessitant une version de MySQL qui ne fonctionne qu'avec la version Y de Linux. Mais avec la virtualisation, vous n'avez pas besoin de vous battre pour savoir quelle version de Linux exécuter sur les machines serveur de votre entreprise. Au lieu de cela, vous pouvez chacun avoir vos propres machines virtuelles exécutant la version dont vous avez besoin. Plus important encore, même si le système de virtualisation lui-même nécessite la version Z de Linux, ce n'est toujours pas un problème, car il se situe à un niveau d'abstraction différent.

Virtualization doesn’t just free us from fights over which version of Linux to use, but which operating system entirely. With virtualization you can run Linux on Windows, or Windows on Mac, or FreeBSD on Linux, or whatever. In particular, it means you can run Linux on seL4. This is interesting because all the mainstream operating systems have structural vulnerabilities that mean they inevitably tend to get breached, and when somebody gets into the OS that’s running the virtualization layer it means they get into all the hosted VMs as well, regardless of their OS. While it’s still early days, initial indications are that seL4 makes a much more solid base for the virtualization layer than Linux or the others, while still allowing the vast bulk of the code that needs to run to continue working in its familiar environment.		La virtualisation ne nous libère pas seulement de la lutte pour savoir quelle version de Linux utiliser, mais également quel système d'exploitation. Avec la virtualisation, vous pouvez exécuter Linux sur Windows, ou Windows sur Mac, ou FreeBSD sur Linux, ou autre. En particulier, cela signifie que vous pouvez exécuter Linux sur seL4. Ceci est intéressant car tous les systèmes d'exploitation traditionnels ont des vulnérabilités structurelles qui signifient qu'ils ont inévitablement tendance à être violés, et lorsque quelqu'un pénètre dans le système d'exploitation qui exécute la couche de virtualisation, cela signifie qu'ils pénètrent également dans toutes les machines virtuelles hébergées, quel que soit leur système d'exploitation. Bien qu'il n'en soit encore qu'à ses débuts, les premières indications sont que seL4 constitue une base beaucoup plus solide pour la couche de virtualisation que Linux ou les autres, tout en permettant à la grande majorité du code qui doit s'exécuter de continuer à fonctionner dans son environnement familier.

By providing a secure base for the virtualization layer, you can provide a safe place to stand for datacenter operators and other providers of virtualized services. You have to replace some of the software that manages your datacenter, but the datacenter’s customers don’t have to change anything to benefit from this; indeed, they need not even be aware that you’ve done it.		En fournissant une base sécurisée pour la couche de virtualisation, vous pouvez fournir un endroit sûr pour les opérateurs de centres de données et d'autres fournisseurs de services virtualisés. Vous devez remplacer certains des logiciels qui gèrent votre centre de données, mais les clients du centre de données n'ont rien à changer pour en bénéficier; en fait, ils n'ont même pas besoin de savoir que vous l'avez fait.

This idea of giving applications a secure place to run, a place where the rules make sense and critical invariants can be relied upon – what I like to call an island of sanity – is not limited to hardware virtualization. “Frozen Realms”, currently working its slow way through the JavaScript standardization process, is a proposal to apply ocap-based compartmentalization principles to the execution environment of JavaScript code in the web browser.		Cette idée de donner aux applications un endroit sûr pour s'exécuter, un endroit où les règles ont du sens et où les invariants critiques peuvent être invoqués - ce que j'aime appeler un îlot de bon sens - ne se limite pas à la virtualisation matérielle. «Frozen Realms», qui travaille actuellement lentement dans le processus de normalisation JavaScript, est une proposition visant à appliquer les principes de compartimentation basés sur ocap à l'environnement d'exécution du code JavaScript dans le navigateur Web.

The stock JavaScript environment is highly plastic; code can rearrange, reconfigure, redefine, and extend what’s there to an extraordinary degree. This massive flexibility is both blessing and curse. On the blessing side, it’s just plain useful. In particular, a piece of code that relies on features or behavior from a newer version of the language standard can patch the environment of an older implementation to emulate the newer pieces that it needs (albeit sometimes with a substantial performance penalty). This malleability is essential to how the language evolves without breaking the web. On the other hand, it makes it treacherous to combine code from different providers, since it’s very easy for one chunk of code to undermine the invariants that another part relies on. This is a substantial maintenance burden for application developers, and especially for the creators of application frameworks and widely used libraries. And this before we even consider what can happen if code behaves maliciously.		L'environnement JavaScript d'origine est hautement plastique; le code peut réorganiser, reconfigurer, redéfinir et étendre ce qui existe à un degré extraordinaire. Cette flexibilité massive est à la fois une bénédiction et une malédiction. Du côté de la bénédiction, c'est tout simplement utile. En particulier, un morceau de code qui repose sur des fonctionnalités ou un comportement d'une version plus récente du standard de langage peut patcher l'environnement d'une implémentation plus ancienne pour émuler les nouveaux éléments dont il a besoin (bien que parfois avec une pénalité de performances substantielle). Cette malléabilité est essentielle à la façon dont le langage évolue sans casser le web. D'un autre côté, il est dangereux de combiner du code de différents fournisseurs, car il est très facile pour un morceau de code de saper les invariants sur lesquels une autre partie s'appuie. Il s'agit d'une charge de maintenance importante pour les développeurs d'applications, et en particulier pour les créateurs de frameworks d'application et de bibliothèques largement utilisées. Et cela avant même de considérer ce qui peut arriver si le code se comporte de manière malveillante.

Frozen Realms is a scheme to let you to create an isolated execution environment, configure it with whatever modifications and enhancements it requires, lock it down so that it is henceforth immutable, and then load and execute code within it. One of the goals of Frozen Realms is to enable defensively consistent software – code that can protect its invariants against arbitrary or improper behavior by things it’s interoperating with. In a frozen realm, you can rely on things not to change beneath you unpredictably. In particular, you could load independent pieces of software from separate developers (who perhaps don’t entirely trust each other) into a common realm, and then allow these to interact safely. Ocaps are key to making this work. All of the ocap coding patterns mentioned earlier become available as trustworthy tools, since the requisite invariants are guaranteed. Because the environment is immutable, the only way pieces of code can affect each other is via object references they pass between them. Because all external authority enters the environment via object references originating outside it, rather than being ambiently available, you have control over what any piece of code will be allowed to do. Most significantly, you can have assurances about what it will not be allowed to do.		Frozen Realms est un schéma qui vous permet de créer un environnement d'exécution isolé, de le configurer avec toutes les modifications et améliorations nécessaires, de le verrouiller pour qu'il soit désormais immuable, puis de charger et d'exécuter du code en son sein. L'un des objectifs de Frozen Realms est d'activer un logiciel cohérent sur le plan défensif - un code qui peut protéger ses invariants contre les comportements arbitraires ou inappropriés des éléments avec lesquels il interagit. Dans un royaume gelé, vous pouvez compter sur les choses pour ne pas changer de façon imprévisible. En particulier, vous pouvez charger des logiciels indépendants de développeurs distincts (qui ne se font peut-être pas entièrement confiance) dans un domaine commun, puis les autoriser à interagir en toute sécurité. Les ocaps sont essentiels pour que cela fonctionne. Tous les modèles de codage ocap mentionnés précédemment deviennent disponibles en tant qu'outils fiables, puisque les invariants requis sont garantis. Étant donné que l'environnement est immuable, la seule façon dont les morceaux de code peuvent s'influencer les uns les autres est via les références d'objets qu'ils passent entre eux. Étant donné que toutes les autorités externes pénètrent dans l'environnement via des références d'objets provenant de l'extérieur, plutôt que d'être disponibles dans l'environnement, vous avez le contrôle sur ce que tout morceau de code sera autorisé à faire. Plus important encore, vous pouvez avoir des assurances sur ce qu'il ne sera pas autorisé à faire.

Distributed services[edit]		Services distribués[ modifier ]

There are many problems in the distributed services arena for which the capability approach can be helpful. In the interest of not making this already long essay even longer, I’ll just talk here about one of the most important: the service chaining problem, for which the ACL approach has no satisfactory solution at all.		Il existe de nombreux problèmes dans le domaine des services distribués pour lesquels l'approche par capacités peut être utile. Dans l'intérêt de ne pas prolonger encore plus cet essai déjà long, je vais juste parler ici de l'un des plus importants: le problème de chaînage de services, pour lequel l'approche ACL n'a pas du tout de solution satisfaisante.

The web is a vast ecosystem of services using services using services. This is especially true in the corporate world, where companies routinely contract with specialized service providers to administer non-core operational functions like benefits, payroll, travel, and so on. These service providers often call upon even more specialized services from a range of other providers. Thus, for example, booking a business trip may involve going through your company’s corporate intranet to the website of the company’s contracted travel agency, which in turn invokes services provided by airlines, hotels, and car rental companies to book reservations or purchase tickets. Those services may themselves call out to yet other services to do things like email you your travel itinerary or arrange to send you a text if your flight is delayed.		Le web est un vaste écosystème de services utilisant des services utilisant des services. Cela est particulièrement vrai dans le monde de l'entreprise, où les entreprises contractent régulièrement avec des fournisseurs de services spécialisés pour administrer des fonctions opérationnelles non essentielles telles que les avantages sociaux, la paie, les voyages, etc. Ces fournisseurs de services font souvent appel à des services encore plus spécialisés d'une gamme d'autres fournisseurs. Ainsi, par exemple, la réservation d'un voyage d'affaires peut impliquer de passer par l'intranet d'entreprise de votre entreprise au site Web de l'agence de voyages sous contrat de l'entreprise, qui à son tour fait appel aux services fournis par les compagnies aériennes, les hôtels et les sociétés de location de voitures pour réserver ou acheter des billets. Ces services peuvent eux-mêmes faire appel à d'autres services pour vous faire parvenir par e-mail votre itinéraire de voyage ou vous envoyer un SMS en cas de retard de votre vol.

Now we have the question: if you invoke one service that makes use of another, whose credentials should be used to access the second one? If the upstream service uses its own credentials, then it might be fooled, by intention or accident, into doing something on your behalf that it is allowed to do but which the downstream service wouldn’t let you do (a classic instance of the Confused Deputy problem). On the other hand, if the upstream service needs your credentials to invoke the downstream service, it can now do things that you wouldn’t allow. In fact, by giving it your credentials, you’ve empowered it to impersonate you however it likes. And the same issues arise for each service invocation farther down the chain.		Maintenant, nous avons la question: si vous invoquez un service qui en utilise un autre, dont les informations d'identification doivent être utilisées pour accéder au second? Si le service en amont utilise ses propres informations d'identification, il peut être dupé, intentionnellement ou accidentellement, en faisant quelque chose en votre nom qu'il est autorisé à faire mais que le service en aval ne vous laisserait pas faire (une instance classique de Confused Problème adjoint). D'un autre côté, si le service en amont a besoin de vos informations d'identification pour appeler le service en aval, il peut désormais faire des choses que vous n'autoriseriez pas. En fait, en lui donnant vos informations d'identification, vous lui avez donné le pouvoir de vous faire passer comme il l'entend. Et les mêmes problèmes se posent pour chaque appel de service plus bas dans la chaîne.

Consider, for example, a service like Mint that keeps track of your finances and gives you money management advice. In order to do this, they need to access banks, brokerages, and credit card companies to obtain your financial data. When you sign up for Mint, you give them the login names and passwords for all your accounts at all the financial institutions you do business with, so they can fetch your information and organize it for you. While they promise they’re only going to use these credentials to read your data, you’re actually giving them unlimited access and trusting them not to abuse it. There’s no reason to believe they have any intention of breaking their promise, and they do, in fact, take security very seriously. But in the end the guarantee you get comes down to “we’re a big company, if we messed with you too badly we might get in trouble”; there are no technical assurances they can really provide. Instead, they display the logos of various security promoting consortia and double pinky swear they’ll guard your credentials with like really strong encryption and stuff. Moreover, their terms of use work really hard to persuade you that you have no recourse if they fail (though who actually gets stuck holding the bag in the event they have a major security breach is, I suspect, virgin territory, legally speaking).		Prenons l'exemple d'un service comme Mint qui fait le suivi de vos finances et vous donne des conseils en matière de gestion financière. Pour ce faire, ils doivent accéder aux banques, aux maisons de courtage et aux sociétés de cartes de crédit pour obtenir vos données financières. Lorsque vous vous inscrivez à Mint, vous leur donnez les noms de connexion et les mots de passe pour tous vos comptes dans toutes les institutions financières avec lesquelles vous faites affaire, afin qu'ils puissent récupérer vos informations et les organiser pour vous. Bien qu'ils promettent qu'ils n'utiliseront ces informations d'identification que pour lire vos données, vous leur donnez en fait un accès illimité et leur faites confiance pour ne pas en abuser. Il n'y a aucune raison de croire qu'ils ont l'intention de rompre leur promesse, et ils prennent en fait la sécurité très au sérieux. Mais en fin de compte, la garantie que vous obtenez se résume à «nous sommes une grande entreprise, si nous vous avons trop malmené, nous pourrions avoir des ennuis »; il n'y a aucune assurance technique qu'ils peuvent vraiment fournir. Au lieu de cela, ils affichent les logos de divers consortiums de promotion de la sécurité et jurent qu'ils protégeront vos informations d'identification avec un cryptage très fort et des trucs. De plus, leurs conditions d'utilisation travaillent très dur pour vous persuader que vous n'avez aucun recours en cas d'échec (bien que qui reste coincé en tenant le sac en cas de faille de sécurité majeure est, je soupçonne, un territoire vierge, juridiquement parlant).

While I’m quite critical of them here, I’m not actually writing this to beat up on them. I’m reasonably confident (and I say this without knowing or having spoken to anyone there, merely on the basis of having been in management at various companies myself) that they would strongly prefer not to be in the business of running a giant single point of failure for millions of people’s finances. It’s just that given the legacy security architecture of the web, they have no practical alternative, so they accept the risk as a cost of doing business, and then invest in a lot of complex, messy, and very expensive security infrastructure to try to minimize that risk.		Bien que je sois assez critique à leur égard ici, je n'écris pas vraiment cela pour les battre. Je suis raisonnablement convaincu (et je le dis sans le savoir ni en avoir parlé à qui que ce soit, simplement parce que j'ai moi-même été à la direction de diverses entreprises) qu'ils préféreraient fortement ne pas gérer un point unique géant. de l'échec pour les finances de millions de personnes. C'est juste qu'étant donné l'architecture de sécurité héritée du Web, ils n'ont pas d'alternative pratique, ils acceptent donc le risque comme un coût de faire des affaires, puis investissent dans de nombreuses infrastructures de sécurité complexes, désordonnées et très coûteuses pour essayer de minimiser ce risque.

To someone steeped in capability concepts, the idea that you would willingly give strangers on the web unlimited access to all your financial accounts seems like madness. I suspect it also seems like madness to lay people who haven’t drunk the conventional computer security kool aid, evidence of which is the lengths Mint has to go to in its marketing materials trying to persuade prospective customers that, no really, this is OK, trust us, please pay no attention to the elephant in the room.		Pour quelqu'un imprégné de concepts de capacités, l'idée que vous donneriez volontiers à des inconnus sur le Web un accès illimité à tous vos comptes financiers semble être une folie. Je soupçonne que cela semble aussi être de la folie pour les profanes qui n'ont pas bu le kool aid de sécurité informatique conventionnel, dont la preuve est les efforts que Mint doit faire dans ses supports marketing pour essayer de persuader les clients potentiels que, non vraiment, c'est OK , faites-nous confiance, ne faites pas attention à l'éléphant dans la pièce.

The capability alternative (which, I stress, is not an option currently available to you), would be to obtain a separate credential – a capability! – from each of your financial institutions that you could pass along to a data management service like Mint. These credentials would grant read access to the relevant portions of your data, while providing no other authority. They would also be revocable, so that you could unilaterally withdraw this access later, say in the event of a security breach at the data manager, without disrupting your own normal access to your financial institutions. And there would be distinct credentials to give to each data manager that you use (say, you’re trying out a competitor to Mint) so that they could be independently controlled.		L'alternative de capacité (qui, je le souligne, n'est pas une option actuellement disponible pour vous), serait d'obtenir un justificatif distinct - une capacité! - de chacune de vos institutions financières que vous pourriez transmettre à un service de gestion de données comme Mint. Ces informations d'identification donneraient un accès en lecture aux parties pertinentes de vos données, sans fournir d'autre autorité. Ils seraient également révocables, afin que vous puissiez retirer unilatéralement cet accès ultérieurement, par exemple en cas de faille de sécurité chez le gestionnaire de données, sans perturber votre propre accès normal à vos institutions financières. Et il y aurait des informations d'identification distinctes à donner à chaque gestionnaire de données que vous utilisez (par exemple, vous essayez un concurrent de Mint) afin qu'ils puissent être contrôlés indépendamment.

There are no particular technical obstacles to doing any of this. Alan Karp worked out much of the mechanics at HP Labs in a very informative paper called “Zebra Copy: A reference implementation of federated access management” that should be on everyone’s must read list.		Il n'y a aucun obstacle technique particulier à faire quoi que ce soit. Alan Karp a mis au point une grande partie des mécanismes de HP Labs dans un article très instructif intitulé «Zebra Copy: Une implémentation de référence de la gestion des accès fédérés» qui devrait figurer sur la liste des personnes à lire absolument.

Even with existing infrastructure and tools there are many available implementation options. Alan worked it out using SAML certificates, but you can do this just as well with OAuth2 bearer tokens, or even just special URLs. There are some new user interface things that would have to be done to make this easy and relatively transparent for users, but there’s been a fair bit of experimentation and prototyping done in this area that have pointed to a number of very satisfactory and practical UI options. The real problem is that the various providers and consumers of data and services would all have to agree that this new way of doing things is desirable, and then commit to switching over to it, and then standardize the protocols involved, and then actually change their systems, whereas the status quo doesn’t require any such coordination. In other words, we’re back to the installed base problem mentioned earlier.		Même avec l'infrastructure et les outils existants, de nombreuses options de mise en œuvre sont disponibles. Alan l'a élaboré à l'aide de certificats SAML, mais vous pouvez le faire aussi bien avec des jetons de support OAuth2, ou même simplement avec des URL spéciales. Il y a de nouvelles choses à faire sur l'interface utilisateur pour rendre cela facile et relativement transparent pour les utilisateurs, mais il y a eu pas mal d'expérimentation et de prototypage dans ce domaine qui ont mis en évidence un certain nombre d'options d'interface utilisateur très satisfaisantes et pratiques. . Le vrai problème est que les différents fournisseurs et consommateurs de données et de services devraient tous convenir que cette nouvelle façon de faire est souhaitable, puis s'engager à y basculer, puis normaliser les protocoles impliqués, puis modifier réellement leur systèmes, alors que le statu quo n’exige pas une telle coordination.

However, web companies and other large enterprises are constantly developing and deploying hordes of new services that need to interoperate, so even if the capability approach is an overreach for the incumbents, it looks to me like a competitive opportunity for ambitious upstarts. Enterprises in particular currently lack a satisfactory service chaining solution, even though they’re in dire need of one.		Cependant, les entreprises du Web et d'autres grandes entreprises développent et déploient constamment des hordes de nouveaux services qui doivent interopérer, donc même si l'approche capacitaire est une portée excessive pour les opérateurs en place, cela me semble être une opportunité concurrentielle pour les débutants ambitieux. Les entreprises en particulier manquent actuellement d'une solution de chaînage de services satisfaisante, même si elles en ont cruellement besoin.

In practice, the main defense against bad things happening in these sorts of systems is not the access control mechanisms at all, it’s the contractual obligations between the various parties. This can be adequate for big companies doing business with other big companies, but it’s not a sound basis for a robust service ecosystem. In particular, you’d like software developers to be able to build services by combining other services without the involvement of lawyers. And in any case, when something does go wrong, with or without lawyers it can be hard to determine who to hold at fault because confused deputy problems are rooted in losing track of who was trying to do what. In essence we have engineered everything with built in accountability laundering.		En pratique, la principale défense contre les mauvaises choses qui se produisent dans ce type de systèmes ne sont pas du tout les mécanismes de contrôle d'accès, ce sont les obligations contractuelles entre les différentes parties. Cela peut convenir aux grandes entreprises qui font des affaires avec d'autres grandes entreprises, mais ce n'est pas une base solide pour un écosystème de services robuste. En particulier, vous aimeriez que les développeurs de logiciels soient en mesure de créer des services en combinant d'autres services sans la participation d'avocats. Et dans tous les cas, quand quelque chose ne va pas, avec ou sans avocats, il peut être difficile de déterminer qui doit être responsable, car les problèmes confus des sous-ministres sont enracinés dans le fait de ne pas savoir qui essayait de faire quoi. En substance, nous avons tout conçu avec un blanchiment de responsabilité intégré.

ACL proponents typically try to patch the inherent problems of identity-based access controls (that is, ones rooted in the “who are you?” question) by piling on more complicated mechanisms like role-based access control or attribute-based access control or policy-based access control (Google these if you want to know more; they’re not worth describing here). None of these schemes actually solves the problem, because they’re all at heart just variations of the same one broken thing: ambient authority. I think it’s time for somebody to try to get away from that.		Les promoteurs d'ACL essaient généralement de corriger les problèmes inhérents aux contrôles d'accès basés sur l'identité (c'est-à-dire ceux qui sont enracinés dans la question «qui êtes-vous?») En empilant des mécanismes plus complexes comme le contrôle d'accès basé sur les rôles ou le contrôle d'accès basé sur les attributs ou contrôle d'accès basé sur des règles (Google ceux-ci si vous voulez en savoir plus; ils ne valent pas la peine d'être décrits ici). Aucun de ces schémas ne résout réellement le problème, car ils ne sont tous au cœur que des variations de la même chose brisée: l'autorité ambiante. Je pense qu'il est temps que quelqu'un essaie de s'éloigner de cela.

Software engineering practices[edit]		Pratiques de génie logiciel[ modifier ]

At Electric Communities we set out to create technology for building a fully decentralized, fully user extensible virtual world. By “fully decentralized” we meant that different people and organizations could run different parts of the world on their own machines for specific purposes or with specific creative intentions of their own. By “fully user extensible” we meant that folks could add new objects to the world over time, and not just new objects but new kinds of objects.		Chez Electric Communities, nous avons décidé de créer une technologie pour créer un monde virtuel entièrement décentralisé et entièrement extensible par l'utilisateur. Par «entièrement décentralisé», nous entendions que différentes personnes et organisations pouvaient faire fonctionner différentes parties du monde sur leurs propres machines à des fins spécifiques ou avec leurs propres intentions créatives. Par «entièrement extensible par l'utilisateur», nous voulions dire que les gens pouvaient ajouter de nouveaux objets au monde au fil du temps, et pas seulement de nouveaux objets, mais de nouveaux types d'objets.

Accomplishing this requires solving some rather hairy authority management problems. One example that we used as a touchstone was the notion of a fantasy role playing game environment adjacent to an online stock exchange. Obviously you don’t want someone taking their dwarf axe into the stock exchange and whacking peoples’ heads off, nor do you want a stock trader visiting the RPG during their lunch break to have their portfolio stolen by brigands. While interconnecting these two disparate applications doesn’t actually make a lot of sense, it does vividly capture the flavor of problems we were trying to solve. For example, if the dwarf axe is a user programmed object, how does it acquire the ability to whack people’s heads off in one place but not have that ability in another place?		Pour y parvenir, il faut résoudre des problèmes de gestion d'autorité plutôt épineux. Un exemple que nous avons utilisé comme pierre de touche était la notion d'un environnement de jeu de rôle fantastique adjacent à une bourse en ligne. De toute évidence, vous ne voulez pas que quelqu'un apporte sa hache naine à la bourse et frappe la tête des gens, ni qu'un négociant en bourse visite le RPG pendant sa pause déjeuner se fasse voler son portefeuille par des brigands. Bien que l'interconnexion de ces deux applications disparates n'ait pas vraiment de sens, elle capture de manière frappante la saveur des problèmes que nous essayions de résoudre. Par exemple, si la hache naine est un objet programmé par l'utilisateur, comment acquiert-elle la capacité de frapper la tête des gens à un endroit sans avoir cette capacité à un autre endroit?

Naturally, ocaps became our power tool of choice, and lots of interesting and innovative technology resulted (the E programming language is one notable example that actually made it to the outside world). However, all the necessary infrastructure was ridiculously ambitious, and consequently development was expensive and time consuming. Unfortunately, extensible virtual world technology was not actually something the market desperately craved, so being expensive and time consuming was a problem. As a result, the company was forced to pivot for survival, turning its attentions to other, related businesses and applications we hoped would be more viable.		Naturellement, ocaps est devenu notre outil puissant de choix, et de nombreuses technologies intéressantes et innovantes en ont résulté (le langage de programmation E est un exemple notable qui a réussi à atteindre le monde extérieur). Cependant, toute l'infrastructure nécessaire était ridiculement ambitieuse et, par conséquent, le développement était coûteux et long. Malheureusement, la technologie du monde virtuel extensible n'était pas vraiment quelque chose dont le marché aspirait désespérément, donc être coûteuse et prendre du temps était un problème. En conséquence, l'entreprise a été obligée de pivoter pour survivre, se tournant vers d'autres activités et applications connexes dont nous espérions qu'elles seraient plus viables.

I mention all of the above as preamble to what happened next. When we shifted to other lines of business, we did so with a portfolio of aggressive technologies and paranoid techniques forged in the crucible of this outrageous virtual world project. We went on using these tools mainly because they were familiar and readily at hand, rather than due to some profound motivating principle, though we did retain our embrace of the ocap mindset. However, when we did this, we made an unexpected discovery: code produced with these tools and techniques had greater odds of being correct on the first try compared to historical experience. A higher proportion of development time went to designing and coding, a smaller fraction of time to debugging, things came together much more quickly, and the resulting product tended to be considerably more robust and reliable. Hmmm, it seems we were onto something here. The key insight is that measures that prevent deliberate misbehavior tend to be good at preventing accidental misbehavior also. Since a bug is, almost by definition, a form of accidental misbehavior, the result was fewer bugs.		Je mentionne tout ce qui précède comme préambule à ce qui s'est passé ensuite. Lorsque nous sommes passés à d'autres secteurs d'activité, nous l'avons fait avec un portefeuille de technologies agressives et de techniques paranoïdes forgées dans le creuset de ce projet de monde virtuel scandaleux. Nous avons continué à utiliser ces outils principalement parce qu'ils étaient familiers et facilement accessibles, plutôt qu'en raison d'un principe de motivation profond, bien que nous ayons conservé notre adhésion à la mentalité ocap. Cependant, lorsque nous avons fait cela, nous avons fait une découverte inattendue: le code produit avec ces outils et techniques avait plus de chances d'être correct au premier essai par rapport à l'expérience historique. Une plus grande proportion du temps de développement est allée à la conception et au codage, une plus petite fraction de temps au débogage, les choses se sont réunies beaucoup plus rapidement, et le produit résultant avait tendance à être considérablement plus robuste et fiable. Hmmm, il semble que nous étions sur quelque chose ici. L'idée clé est que les mesures qui préviennent les mauvaises conduites délibérées ont tendance à être bonnes pour prévenir également les mauvaises conduites accidentelles. Puisqu'un bogue est, presque par définition, une forme de mauvaise conduite accidentelle, le résultat était moins de bogues.

Shorn of all the exotic technology, however, the principles at work here are quite simple and very easy to apply to ordinary programming practice, though the consequences you experience may be far reaching.		Dépourvus de toute technologie exotique, cependant, les principes à l'œuvre ici sont assez simples et très faciles à appliquer à la pratique de programmation ordinaire, même si les conséquences que vous ressentez peuvent être considérables.

As an example, I’ll explain how we apply these ideas to Java. There’s nothing magic or special about Java per se, other than it can be tamed – some languages cannot – and that we’ve had a lot of experience doing so. In Java we can reduce most of it to three simple rules:		À titre d'exemple, je vais vous expliquer comment nous appliquons ces idées à Java. Il n'y a rien de magique ou de spécial à propos de Java en soi, à part qu'il peut être apprivoisé - certains langages ne le peuvent pas - et que nous avons beaucoup d'expérience en la matière. En Java, nous pouvons réduire la plupart d'entre eux à trois règles simples:

Rule #1: All instance variables must be private		Règle n ° 1: toutes les variables d'instance doivent être privées

Rule #2: No mutable static state or statically accessible authority		Règle n ° 2: Aucun état statique mutable ou autorité statiquement accessible

Rule #3: No mutable state accessible across thread boundaries		Règle n ° 3: aucun état mutable accessible à travers les limites de thread

That’s basically it, though Rule #2 does merit a little further explication. Rule #2 means that all static variables must be declared final and may only reference objects that are themselves transitively immutable. Moreover, constructors and static methods must not provide access to any mutable state or side-effects on the outside world (such as I/O), unless these are obtained via objects passed into them as parameters.		C'est fondamentalement cela, bien que la règle n ° 2 mérite un peu plus d'explications. La règle n ° 2 signifie que toutes les variables statiques doivent être déclarées finales et ne peuvent référencer que des objets qui sont eux-mêmes immuables de manière transitoire. De plus, les constructeurs et les méthodes statiques ne doivent pas donner accès à un état mutable ou à des effets secondaires sur le monde extérieur (tels que les E / S), à moins qu'ils ne soient obtenus via des objets qui leur sont passés en tant que paramètres.

These rules simply ensure the qualities of reference unforgeability and encapsulation that I mentioned a while back. The avoidance of static state and static authority is because Java class names constitute a form of forgeable reference, since anyone can access a class just by typing its name. For example, anybody at all can try to read a file by creating an instance of java.io.FileInputStream, since this will open a file given a string. The only limitations on opening a file this way are imposed by the operating system’s ACL mechanism, the very thing we are trying to avoid relying on. On the other hand, a specific instance of java.io.InputStream is essentially a read capability, since the only authority it exposes is on its instance methods.		Ces règles garantissent simplement les qualités de référence infalsifiable et d'encapsulation que j'ai évoquées il y a quelque temps. L'évitement de l'état statique et de l'autorité statique est dû au fait que les noms de classe Java constituent une forme de référence falsifiée, car n'importe qui peut accéder à une classe simplement en tapant son nom. Par exemple, n'importe qui peut essayer de lire un fichier en créant une instance de java.io.FileInputStream, car cela ouvrira un fichier avec une chaîne. Les seules limitations à l'ouverture d'un fichier de cette manière sont imposées par le mécanisme ACL du système d'exploitation, ce sur quoi nous essayons d'éviter de nous fier. D'un autre côté, une instance spécifique de java.io.InputStream est essentiellement une capacité de lecture, puisque la seule autorité qu'elle expose se trouve sur ses méthodes d'instance.

These rules cover most of what you need. If you want to get really extreme about having a pure ocap language, in Java there are a few additional edge case things you’d like to be careful of. And, of course, it would also be nice if the rules could be enforced automatically by your development tools. If your thinking runs along these lines, I highly recommend checking out Adrian Mettler’s Joe-E, which defines a pure ocap subset of Java much more rigorously, and provides an Eclipse plugin that supports it. However, simply following these three rules in your ordinary coding will give you about 90% of the benefits if what you care about is improving your code rather than security per se.		Ces règles couvrent la plupart de ce dont vous avez besoin. Si vous voulez devenir vraiment extrême sur le fait d'avoir un langage ocap pur, en Java, il y a quelques éléments supplémentaires dont vous voudriez faire attention. Et, bien sûr, ce serait également bien si les règles pouvaient être appliquées automatiquement par vos outils de développement. Si votre réflexion va dans ce sens, je vous recommande vivement de consulter Joe-E d'Adrian Mettler, qui définit un sous-ensemble ocap pur de Java beaucoup plus rigoureusement et fournit un plugin Eclipse qui le prend en charge. Cependant, le simple fait de suivre ces trois règles dans votre codage ordinaire vous donnera environ 90% des avantages si vous vous souciez d'améliorer votre code plutôt que la sécurité en soi.

Applying these rules in practice will change your code in profound ways. In particular, many of the standard Java class libraries don’t follow them – for example lots of I/O authority is accessed via constructors and static methods. In practice, what you do is quarantine all the unavoidable violations of Rule #2 into carefully considered factory classes that you use during your program’s startup phase. This can feel awkward at first, but it’s an experience rather like using a strongly typed programming language for the first time: in the beginning you keep wondering why you’re blocked from doing obvious things you want to do, and then it slowly dawns on you that actually you’ve been blocked from doing things that tend to get you into trouble. Plus, the discipline forces you to think through things like your I/O architecture, and the result is generally improved structure and greater robustness.		L'application de ces règles dans la pratique changera votre code de manière profonde. En particulier, la plupart des bibliothèques de classes Java standard ne les suivent pas - par exemple, de nombreuses autorisations d'E / S sont accessibles via des constructeurs et des méthodes statiques. En pratique, ce que vous faites est de mettre en quarantaine toutes les violations inévitables de la règle n ° 2 dans des classes d'usine soigneusement étudiées que vous utilisez pendant la phase de démarrage de votre programme. Cela peut sembler gênant au début, mais c'est une expérience un peu comme utiliser un langage de programmation fortement typé pour la première fois: au début, vous continuez à vous demander pourquoi vous êtes empêché de faire des choses évidentes que vous voulez faire, puis cela apparaît lentement. vous que vous avez été empêché de faire des choses qui ont tendance à vous causer des ennuis. De plus, la discipline vous oblige à réfléchir à des choses comme votre architecture d'E / S,

(Dealing with the standard Java class libraries is a bit of an open issue. The approach taken by Joe-E and its brethren has been to use the standard libraries pruned of the dangerous stuff, a process we call “taming”. But while this yields safety, it’s less than ideal from an ergonomics perspective. A project to produce a good set of capability-oriented wrappers for the functionality in the core Java library classes would probably be a valuable contribution to the community, if anyone out there is so inclined.)		(La gestion des bibliothèques de classes Java standard est un peu une question ouverte. L'approche adoptée par Joe-E et ses frères a été d'utiliser les bibliothèques standard élaguées des éléments dangereux, un processus que nous appelons «apprivoiser». garantit la sécurité, il est loin d'être idéal du point de vue de l'ergonomie. Un projet visant à produire un bon ensemble de wrappers axés sur les capacités pour les fonctionnalités des classes de base de la bibliothèque Java serait probablement une contribution précieuse à la communauté, si quelqu'un le souhaite .)

Something like the three rules for Java can be often devised for other languages as well, though the feasibility of this does vary quite a bit depending on how disciplined the language in question is. For example, people have done this for Scala and OCaml, and it should be quite straightforward for C#, but probably hopeless for PHP or Fortran. Whether C++ is redeemable in this sense is an open question; it seems plausible to me, although the requisite discipline somewhat cuts against the grain of how people use C++. It’s definitely possible for JavaScript, as a number of features in recent versions of the language standard were put there expressly to enable this kind of thing. It’s probably also worth pointing out that there’s a vibrant community of open source developers creating new languages that apply these ideas. In particular, you should check out Monte, which takes Python as its jumping off point, and Pony, which is really its own thing but very promising.		Quelque chose comme les trois règles pour Java peut souvent être conçu pour d'autres langages, bien que la faisabilité de cela varie un peu en fonction de la discipline du langage en question. Par exemple, des gens l'ont fait pour Scala et OCaml, et cela devrait être assez simple pour C #, mais probablement sans espoir pour PHP ou Fortran. La question de savoir si C ++ est remboursable dans ce sens est une question ouverte; cela me semble plausible, même si la discipline requise va quelque peu à l'encontre de la façon dont les gens utilisent le C ++. C'est certainement possible pour JavaScript, car un certain nombre de fonctionnalités dans les versions récentes du standard de langage y ont été expressément mises en place pour permettre ce genre de chose. Il est probablement également intéressant de souligner qu'il existe une communauté dynamique de développeurs open source créant de nouveaux langages qui appliquent ces idées. En particulier,

There’s a fairly soft boundary here between practices that simply improve the robustness and reliability of your code if you follow them, and things that actively block various species of bad outcomes from happening. Obviously, the stronger the discipline enforced by the tools is, the stronger the assurances you’ll have about the resulting product. Once again, the analogy to data types comes to mind, where there are best practices that are basically just conventions to be followed, and then there are things enforced, to a greater or lesser degree, by the programming language itself. From my own perspective, the good news is that in the short term you can start applying these practices in the places where it’s practical to do so and get immediate benefit, without having to change everything else. In the long term, I expect language, library, and framework developers to deliver us increasingly strong tools that will enforce these kinds of rules natively.		Il y a une limite assez douce ici entre les pratiques qui améliorent simplement la robustesse et la fiabilité de votre code si vous les suivez, et les choses qui bloquent activement diverses espèces de mauvais résultats. De toute évidence, plus la discipline imposée par les outils est forte, plus les assurances que vous aurez sur le produit résultant sont fortes. Une fois de plus, l'analogie avec les types de données vient à l'esprit, où il y a des bonnes pratiques qui ne sont essentiellement que des conventions à suivre, puis il y a des choses imposées, à un degré plus ou moins grand, par le langage de programmation lui-même. De mon point de vue, la bonne nouvelle est qu'à court terme, vous pouvez commencer à appliquer ces pratiques là où il est pratique de le faire et obtenir des avantages immédiats, sans avoir à tout changer. A long terme, j'attends la langue, la bibliothèque,

Conclusion[edit]		Conclusion[ modifier ]

At its heart, the capability paradigm is about organizing access control around specific acts of authorization rather than around identity. Identity is so fundamental to how we interact with each other as human beings, and how we have historically interacted with our institutions, that it is easy to automatically assume it should be central to organizing our interactions with our tools as well. But identity is not always the best place to start, because it often fails to tell us what we really need to know to make an access decision (plus, it often says far too much about other things, but that’s an entirely separate discussion).		En son cœur, le paradigme des capacités consiste à organiser le contrôle d'accès autour d'actes d'autorisation spécifiques plutôt que autour de l'identité. L'identité est si fondamentale dans la façon dont nous interagissons les uns avec les autres en tant qu'êtres humains et dans la façon dont nous avons historiquement interagi avec nos institutions, qu'il est facile de supposer automatiquement qu'elle devrait également être centrale dans l'organisation de nos interactions avec nos outils. Mais l'identité n'est pas toujours le meilleur point de départ, car elle ne nous dit souvent pas ce que nous devons vraiment savoir pour prendre une décision d'accès (en plus, elle en dit souvent beaucoup trop sur d'autres choses, mais c'est une discussion entièrement séparée).

Organizing access control around the question “who are you?” is incoherent, because the answer is fundamentally fuzzy. The driving intuition is that the human who clicked a button or typed a command is the person who wanted whatever it was to happen. But this is not obviously true, and in some important cases it’s not true at all. Consider, for example, interacting with a website using your browser. Who is the intentional agent in this scenario? Well, obviously there’s you. But also there are the authors of every piece of software that sits between you and the site. This includes your operating system, the web browser itself, the web server, its operating system, and any other major subsystems involved on your end or theirs, plus the thousands of commercial and open source libraries that have been incorporated into these systems. And possibly other stuff running on your (or their) computers at the time. Plus intermediaries like your household or corporate wireless access point, not to mention endless proxies, routers, switches, and whatnot in the communications path from here to there. And since you’re on a web page, there’s whatever scripting is on the page itself, which includes not only the main content provided by the site operators but any of the other third party stuff one typically finds on the web, such as ads, plus another unpredictably large bundle of libraries and frameworks that were used to cobble the whole site together. Is it really correct to say that any action taken by this vast pile of software was taken by you? Even though the software has literally tens of thousands of authors with a breathtakingly wide scope of interests and objectives? Do you really want to grant all those people the power to act as you? I’m fairly sure you don’t, but that’s pretty much what you’re actually doing, quite possibly thousands of times per day. The question that the capability crowd keeps asking is, “why?”		Organiser le contrôle d'accès autour de la question "qui êtes-vous?" est incohérente, car la réponse est fondamentalement floue. L'intuition motrice est que l'humain qui a cliqué sur un bouton ou tapé une commande est la personne qui voulait que quoi que ce soit se produise. Mais ce n'est évidemment pas vrai, et dans certains cas importants, ce n'est pas du tout vrai. Envisagez, par exemple, d'interagir avec un site Web à l'aide de votre navigateur. Qui est l'agent intentionnel dans ce scénario? Eh bien, il y a évidemment vous. Mais il y a aussi les auteurs de chaque logiciel qui se trouve entre vous et le site. Cela inclut votre système d'exploitation, le navigateur Web lui-même, le serveur Web, son système d'exploitation et tout autre sous-système majeur impliqué de votre côté ou du leur, ainsi que les milliers de bibliothèques commerciales et open source qui ont été incorporées dans ces systèmes. Et peut-être d'autres choses fonctionnant sur vos (ou leurs) ordinateurs à l'époque. De plus, des intermédiaires comme votre point d'accès sans fil domestique ou d'entreprise, sans parler des proxys, des routeurs, des commutateurs, etc. sans fin dans le chemin de communication d'ici à là. Et comme vous êtes sur une page Web, il y a tout le script sur la page elle-même, qui comprend non seulement le contenu principal fourni par les opérateurs du site, mais tout autre élément tiers que l'on trouve généralement sur le Web, comme les publicités, plus un autre ensemble imprévisible de bibliothèques et de cadres qui ont été utilisés pour bricoler l'ensemble du site. Est-il vraiment correct de dire que toute action entreprise par cette vaste pile de logiciels a été prise par vous? Même si le logiciel compte littéralement des dizaines de milliers d'auteurs avec un éventail d'intérêts et d'objectifs à couper le souffle? Voulez-vous vraiment donner à toutes ces personnes le pouvoir d'agir comme vous? Je suis à peu près sûr que vous ne le faites pas, mais c'est à peu près ce que vous faites réellement, probablement des milliers de fois par jour. La question que la foule des capacités ne cesse de se poser est: «pourquoi?»

Several years ago, the computer security guru Marcus Ranum wrote: “After all, if the conventional wisdom was working, the rate of systems being compromised would be going down, wouldn’t it?” I have no idea where he stands on capabilities, nor if he’s even aware of them, but this assertion still seems on point to me.		Il y a plusieurs années, le gourou de la sécurité informatique Marcus Ranum a écrit: «Après tout, si la sagesse conventionnelle fonctionnait, le taux de compromission des systèmes diminuerait, n'est-ce pas? Je n'ai aucune idée de sa position sur les capacités, ni s'il en est même conscient, mais cette affirmation me semble toujours pertinente.

I’m on record comparing the current state of computer security to the state of medicine at the dawn of the germ theory of disease. I’d like to think of capabilities as computer security’s germ theory. The analogy is imperfect, of course, since germ theory talks about causality whereas here we’re talking about the right sort of building blocks to use. But I keep being drawn back to the parallel largely because of the ugly and painful history of germ theory’s slow acceptance. On countless occasions I’ve presented capability ideas to folks who I think ought know about them – security people, engineers, bosses. The typical response is not argument, but indifference. The most common pushback, when it happens, is some variation of “you may well be right, but…”, usually followed by some expression of helplessness or passive acceptance of the status quo. I’ve had people enthusiastically agree with everything I’ve said, then go on to behave as if these ideas had never ever entered their brains. People have trouble absorbing ideas that they don’t already have at least some tentative place for in their mental model of the world; this is just how human minds work. My hope is that some of the stuff I’ve written here will have given these ideas a toehold in your head.		J'ai déjà comparé l'état actuel de la sécurité informatique à l'état de la médecine à l'aube de la théorie des germes de la maladie. J'aimerais considérer les capacités comme la théorie des germes de la sécurité informatique. L'analogie est imparfaite, bien sûr, puisque la théorie des germes parle de causalité alors que nous parlons ici du bon type de blocs de construction à utiliser. Mais je continue à être ramené au parallèle en grande partie à cause de l'histoire laide et douloureuse de la lente acceptation de la théorie des germes. À d'innombrables occasions, j'ai présenté des idées de capacités à des personnes qui, à mon avis, devraient les connaître - des agents de sécurité, des ingénieurs, des patrons. La réponse typique n'est pas un argument, mais l'indifférence. Le refus le plus courant, lorsqu'il se produit, est une variante de «vous avez peut-être raison, mais…», généralement suivie d'une expression d'impuissance ou d'acceptation passive du statu quo. J'ai eu des gens d'accord avec enthousiasme avec tout ce que j'ai dit, puis ils ont continué à se comporter comme si ces idées n'avaient jamais pénétré dans leur cerveau. Les gens ont du mal à absorber des idées pour lesquelles ils n'ont pas déjà au moins une place provisoire dans leur modèle mental du monde; c'est ainsi que fonctionnent les esprits humains. J'espère que certaines des choses que j'ai écrites ici auront donné à ces idées une prise en main dans votre tête.

Acknowledgements[edit]		Remerciements[ modifier ]

This essay benefitted from a lot of helpful feedback from various members of the Capabilities Mafia, the Friam group, and the cap-talk mailing list, notably David Bruant, Raoul Duke, Bill Frantz, Norm Hardy, Carl Hewitt, Chris Hibbert, Baldur Jóhannsson, Alan Karp, Kris Kowal, William Leslie, Mark Miller, David Nicol, Kevin Reid, and Dale Schumacher. My thanks to all of them, whose collective input improved things considerably, though of course any remaining errors and infelicities are mine.		Cet essai a bénéficié de nombreux retours utiles de la part de divers membres de Capabilities Mafia, du groupe Friam et de la liste de diffusion cap-talk, notamment David Bruant, Raoul Duke, Bill Frantz, Norm Hardy, Carl Hewitt, Chris Hibbert, Baldur Jóhannsson , Alan Karp, Kris Kowal, William Leslie, Mark Miller, David Nicol, Kevin Reid et Dale Schumacher. Mes remerciements à tous, dont la contribution collective a considérablement amélioré les choses, même si bien sûr toutes les erreurs et infélicités restantes sont les miennes.

Technology Theory | Posted by Chip at 1:11 PM | You can comment, or send a trackback from your own site.		Théorie de la technologie | Publié par Chip à 13:11 | Vous pouvez commenter ou envoyer un trackback depuis votre propre site.

3 Comments[edit]		3 commentaires[ modifier ]

Hi.		Salut.

Thank you for this great piece of work. It’s the most comprehensive and easy essay about capabilities I’ve read. I started being interested in them when I gave Pony a try, two years ago.		Merci pour ce beau travail. C'est l'essai le plus complet et le plus simple sur les capacités que j'ai lu. J'ai commencé à m'intéresser à eux lorsque j'ai essayé Pony, il y a deux ans.

I’d like to mention the fact that in Pony capabilities are more related to data safety (in the context of highly parallel computation) than to security. Pony uses capabilities to control how actors access the data, thus it can statically prove you’re not doing something stupid (like writing an otherwise readable field). This allows safe mutable data structures in parallel computation with the benefit of ultra fast zero-copy message-passing because the compiler can prove that the passed references won’t be read or written in the caller’s code.		Je voudrais mentionner le fait que dans Pony les capacités sont plus liées à la sécurité des données (dans le contexte d'un calcul hautement parallèle) qu'à la sécurité. Pony utilise des capacités pour contrôler la façon dont les acteurs accèdent aux données, il peut donc prouver statiquement que vous ne faites pas quelque chose de stupide (comme écrire un champ autrement lisible). Cela permet des structures de données mutables sûres dans le calcul parallèle avec l'avantage d'un passage de message ultra rapide sans copie, car le compilateur peut prouver que les références passées ne seront ni lues ni écrites dans le code de l'appelant.

In a sense, it’s the capabilities-thinking-makes-better-code idea you mention in the last part of the essay ported to the heart of the language. In Pony, capabilities don’t even exist at runtime (though it may be a good idea to implement them for security purpose, but it’s left to the developer).		En un sens, c'est l'idée de capacités-penser-rendre-meilleur-code que vous mentionnez dans la dernière partie de l'essai porté au cœur du langage. Dans Pony, les fonctionnalités n'existent même pas au moment de l'exécution (même si cela peut être une bonne idée de les implémenter pour des raisons de sécurité, mais c'est laissé au développeur).

I wasn’t comfortable with the concept of ambient authority (which sometimes raises in Pony) and it now makes much more sense. Thank you!		Je n'étais pas à l'aise avec le concept d'autorité ambiante (qui monte parfois dans Pony) et cela a maintenant beaucoup plus de sens. Je vous remercie!

Posted by: Lisael | January 8, 2018, 4:07 pm		Publié par: Lisael | 8 janvier 2018, 16h07

Hi Chip,		Salut Chip,

This was a very intriguing discussion. I’ve shown it around to a few of the people on our team (Komodo: komodoplatform.com ).		Ce fut une discussion très intéressante. Je l'ai montré à quelques personnes de notre équipe (Komodo: komodoplatform.com).

It would be interesting to chat with you via text message at some point. Is there anywhere we can reach out?		Il serait intéressant de discuter avec vous par SMS à un moment donné. Y a-t-il un endroit où nous pouvons atteindre?

My email address is in the comment submission. Hope to hear from you.		Mon adresse e-mail est dans la soumission du commentaire. J'espère avoir de tes nouvelles.

Posted by: Sidd C | January 8, 2019, 11:50 am		Publié par: Sidd C | 8 janvier 2019, 11h50

Thank you for a comprehensive introduction! I am starting a new job as a software engineer in a security team and I wonder about possible ways to build capabilities based software system inside a largely role-based one. Have people done that, are they satisfied with results, words of caution, anything they might want to share would be appreciated. Thank you!		Merci pour une introduction complète! Je commence un nouveau travail en tant qu'ingénieur logiciel dans une équipe de sécurité et je m'interroge sur les moyens possibles de créer un système logiciel basé sur les capacités dans un système largement basé sur les rôles. Demandez aux gens de faire cela, sont-ils satisfaits des résultats, des mots d'avertissement, tout ce qu'ils voudraient partager serait apprécié. Je vous remercie!