Ben Laurie’s Capabilities

The blog of Ben Laurie is on my blog roll since ages (well, Internet ages). He often has great and refreshing views on topics like identity, privacy or security. On top of that, the quality of the post has always been excellent. If you don’t have his feed in your reader, now would be a good time to include it.

One of the recent posts was about a paper he wrote on capability based security systems. I knew from university that depending on how you read a matrix mapping users, resources and access rights, it would be an access control list or a capability list. Therefore it looks at first sight as if access control lists and capability lists are semantically the same. You either store the rights on the resource itself and it becomes an access control list (most common example is a filesystem). You can store all the rights associated with a particular user and it becomes a capability list. Perhaps this was a simplification done in the textbook we had but it certainly has a degree of logic to it. As Ben explains there is a subtle difference between the two concepts and although they have a lot in common, they are not entirely identical in terms of protecting access to resources.

A good example of the difference between a system based on access control lists or a system based on capabilities is given by Ben in the paper. In a typical application, when a user needs to safe a file, the user is presented with a Select File dialog. Based on this selection the application will ask the operating system to open the file. Based on the access control list on that file, the operation will be allowed or not. In a capability based system, the Select File dialog could be a trusted component presented by the operating system, similar to the card selector of Infocards in Windows. The selection of a file would result in a capability to open that particular file. The application can then use the capability to access the file. In an access control list based system, the file selected by the user is not necessarily the file being accessed by the application. If the applications intentions are not good, it might decide to open a different file. In the capability based system, this would not be possible.

Ben also states that there is room for both systems: access control lists and capability based systems. Depending on the environment and the specific requirements, one system will be better suited then the other. In particular Ben sees capability based systems as very promising in the context of securing various (semi) executable content in web pages. Examples include HTML and scripted content from foreign sources in a web page. A technique more and more used in social networking sites or personal portals as iGoogle.

Although I agree with Ben’s reasoning (who am I to question his experience and knowledge) there are some points in the whitepaper that I don’t fully agree with. In some of the later examples of the whitepaper, Ben starts to play with capabilities. By wrapping them in security containers (for instance signing) they can be passed over untrusted third parties. Capabilities can also be wrapped inside other capabilities to accomplish further control over the right granted.

In most of the paper, the definition of a capability can be fairly strict: it’s represents a capability, something the bearer can do with a resources (or a set of resources, whatever the capability points at). In the examples later in the paper, this definition does not hold anymore and suddenly widens to mean a lot of things. In section 6.3 (“Proving User Choice”) of the white paper a trusted component needs to pass a user action to a second trusted component. It does however use an untrusted intermediate for this. In order to prevent the untrusted intermediate to play with this, the performed user action is represented as a capability. It depends on the definition of a capability of course, but I have a hard time thinking of “the user clicked on the second image” as being a capability. This is more like a claim issued by a trusted component (the trusted renderer in the example). To me a claim is not a capability.

It is probably a matter of defining “claim” and “capability” of course. Perhaps Ben can shed some light on this?