Capability Myths Demolished – Miller et. al 2003

Pretty much everyone is familiar with an ACL-based approach to security. Despite having been around for a very long time, the capabilities approach to security is less well-known. Today’s paper choice provides an excellent introduction to the capabilities model and how it compares to ACLs. Along the way we’ll learn about 7 fundamental properties of security systems, and which combinations of those are required to offer certain higher-level guarantees. Capabilities are central to the type system of the Pony language which we’ll be looking at tomorrow.

Let’s start out by looking at one of the fundamental differences between ACLs and capabilities, the direction of the relationship between subject and resource. Consider a classic access matrix such as the one below. Each row is a subject, and each column a resource. The entry in a given cell describes the permissions the subject has for that resource.

An ACL based system organises by column. For any given resource, we manage a list of subjects and the permissions that they have with respect to that resource. A capabilities based system organises by row, for any given subject we manage all the kinds of access available to that subject. On the surface then, it appears that ACLs and capabilities are just different ways of presenting the same fundamental information. However, on deeper examination the shift in perspective brings about at least three significant differences between the models.

1. ACLs require a shared namespace for resources, whereas capabilities do not. Consider a subject holding some kind of reference to a resource. In an ACL system it is necessary to translate the reference into a name that identifies the resource in a shared namespace and therefore can be used to determine allowable actions. The reference (resource designator) is independent of the permissions. In a capabilities system, a capability points from a subject to a resource and combines the notions of designation and the authority to perform access. This means there is the option to avoid building a shared namespace into the model and hence to avoid the issues related to managing that. The ability to couple designation and authority is our first property: Property A: No designation without authority.
2. In an ACL system it is necessary to maintain up-to-date knowledge of the set of subjects and their designations. As subjects come and go this can easily become a burden, thus practical ACL based systems use coarse-grained subjects such as people or process equivalence classes – principals. In a capability-based system subjects can be much finer-grained – for example, an object instance. It is no problem for new subjects to be created all the time. This leads to Property B: Dynamic Subject Creation.
3. ACL systems aggregate the permission to edit the permissions themselves by resource. In capability systems the ability to edit authorities is aggregated by subject. Property C: Subject Aggregated Authority Management.

Some security systems do not require a subject to indicate a specific authority in order to exercise it. For example, Unix file system permissions use an ambient authority model – you don’t explicitly choose credentials to associated with an open() request for example. Object capability systems do not require an ambient authority. Property D: No Ambient Authority

When subjects and resources are separate you cannot unify access (to a resource) and authority (granted to a subject). In the object capability model, every subject is a resource, and conceptually every resource is a subject (“though some resources, such as the number 3, are primitively provided.”).

Consequently, access and authorization can be unified. This uniformity makes the object-capability model compositional; networks of authority relationships can be composed to any depth. We will refer to this property as Property E: Composability of Authorities.

Authorizations are conveyed in the context of a request. They thus ‘ride on a capability,’ and access to a resource/subject is a prerequisite for delegating authority to that subject. This is Property F: Access-Controlled Delegation Channels.

The POSIX capabilities model has all six of the properties mentioned so far. But it is coarse-grained and the set of resources is fixed:

At the level of detail that we typically care about (individual files, programs, and so on) resources are created and destroyed all the time. There is a bounded set of POSIX capability flags only because they do not express authorities at this level of detail. For example, one of the POSIX capability flags is CAP_CHOWN, which represents the power to change the ownership of any file on the entire system. Just as with the subject granularity issue, we can consider this a granularity
issue with respect to resources, where the ability to dynamically create new resources is the clear dividing line between “fine-grained” and “coarse-grained”.

In contrast, an object capabilities model supports Property G: Dynamic Resource Creation.

Let’s recap the 7 properties, and how we can tell if they hold or not:

• A: No Designation without Authority. Holds if designating a resource always conveys its corresponding authority.
• B: Dynamic Subject Creation. Holds if subjects can dynamically create new subjects.
• C: Subject-Aggregated Authority Management. Holds if the power to edit authorities is aggregated by subject.
• D: No Ambient Authority. Holds if subjects must select which authority to use when performing an access.
• E: Composability of Authorities. Holds if resources are also subjects.
• F: Access-Controlled Delegation Channels. Holds if an access relationship between X and Y is required for X to pass an authority to Y.
• G: Dynamic Resource Creation. Holds if new resources can be dynamically created.

Object-capabilities systems hold all seven of these properties. If some system has property B, but not property E, then revoking delegated rights is not possible. If a system has property B, but not property F, then confining delegated rights is not possible. Without property D (and ideally A), confused deputies cannot be prevented. A confused deputy is a program that must manage authorities coming from multiple sources, and can be manipulated into wielding authority inappropriately. To uphold the secure systems principle of least privilege properties B and G are both required.

The paper concludes with a handy comparison table of various systems and models:

Furthermore, the properties we identified show that capability systems lack certain fatal flaws of ACL systems – namely, the susceptibility of ACLS to the confused deputy problems that are inherent in ambient authority systems, and the inability of ACLs to perform least-privilege delegation to new processes. Capability-based systems provide much stronger support for the precise, minimal, and meaningful delegation of authority, which is fundamental to secure operation.