Comprehensive starter article on capabilities, by Chip.
- 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.
- A capability is single thing that both designates a resource and authorizes some kind of access to it.
- Norm Hardy’s motto: “don’t separate designation from authority”
- By designation, we mean indicating specifically which resource we’re talking about.
- And by authorizing we mean that we are allowing the access to happen.
- capabilities are transferable “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.”
- object capabilities require 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
- capabilities must be unforgeable “you can’t by yourself create a capability to a resource that you don’t already have access to”
- in an object capabilitiy (ocap) system, a reference to an object is a capability.
- objects both wield capabilities and are resources themselves
- Principle of Least Authority (POLA):
- Creation
- 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.
- Transfer
- Capability passing is how the authority graph – the map of who has what authority to do what with what – can change over time
- the lack of a principled way to talk about how authorities change over time is another big problem with the ACL model
- Endowment
- 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.
- creation + transfer
- can use to have an immutable object that holds a capability
- avoid infinite regress
In OCaps, 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).
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.
- One object modulates access to another object
- Example: revoker
Instead of giving my reference (capability), I give an intermediate object that holds my capability but remains controlled by me. Example: a message forwarder that can later drop its forwarding pointer.
- The revoker pattern can be extended to enable delegation to be auditable
- Can switch on or off, can depend on time, date, location, etc.
- Can put control on the frequency or quantity used
- Example: Use-once capability with a built-in expiration date
- Example: An intermediate object that requires payment in exchange for access, etc
- capabilities are essentially bearer instruments – they convey their authority to whoever holds them, without regard to who the holder is
- reducing a capability’s scope of authority
- Example: An OCap may have access to a computer’s file system. Using attenuation, we can return an intermediary capability of just a particular file or subdirectory.
- Read-only access
- useful for packaging access to existing, non-capablity oriented world into capabilities
- mediate access to network communications
- limit connections to particular domains
- allow applications to be securely distributed across datacenters without enabling them to 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
- Packing lower level capabilities into more convenient APIs
- example: package read-only file cap into an input steram object
- example: Unix `passwd` command is an example of abstracting lower level details of file access and data formats
- Uses two or more capabilities together to create a new capability to some specific joint functionality, or create something truly new
- Example: In a Cap OS for mobile smartphones, having a combined capability composed of the authority to capture images with camera, the authority to obtain position with GPS, the authority to read system clock.
Capabilities are a good way to organize an OS.
- KeyKOS Developed in 1980s for IBM mainframes. Code for KeyKos is open source. Has inspired:
- seL4 is a secure variant of the L4 operating system. Also open source.
- often don’t need to depend on legacy systems and can be more stand alone, and so these operating systems can be an opportunity for embedded devices
- recent security incidents around compromised IoT devices highlight the vulnerability of application code that have unfettered access to the underlying hardware. This massive violation of least privilege then makes these devices highly vulnerable to exploitation when an attacker finds flaws in the application code.
- Rigorously compartmentalizing available functionality would greatly reduce the chances of these kinds of vulnerabilities
- Developers would like to build more secure systems. “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.”
- Safety-through-compartmentalization: isolate independent pieces of computation so they can’t interfere with each other
- 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
- 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
- Virtualization doesn’t just free us from fights over which version of Linux to use, but which operating system entirely
- Can run Linux on seL4
- Frozen Realms - capability-based containment module on the road to ecmascript standardization
the service chaining problem: One service requests another service, perhaps requesting yet another service. Whose authority is used/needed? If you give credentials to one, it can exercise any authority you can on your behalf, perhaps maliciously or in undesired or unintended ways and can be a source of exploitation.
- Examples of implementing ocaps in existing infrastructure
- Alan Karp’s Zebra Copy: A Reference Implementation of Federated Access Management: Federated Identity Management for services that cross enterprise boundaries
- Security Assertion Markup Language - Wikipedia
- RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage
Capabilities as applied in software application, such as language usage/design.
- “code produced with [object capabilities tools] and techniques had greater odds of being correct on the first try compared to historical experience”
- “The key insight is that measures that prevent deliberate misbehavior tend to be good at preventing accidental misbehavior also”
- E programming language
- Joe-E - Wikipedia - a pure ocap subset of Java
- taming: pruning the standards library of unsafe code
- Rules for taming Java:
- All instance variables must be private
- No mutable static state or statically accessible authority
- static variables must be declared `final`
- may only reference objects that are themselves transitively immutable
- constructors and static methods must not provide access to any mutable state or side-effects
- No mutable state accessible across thread boundaries
- These rules simply ensure the qualities of reference unforgeability and encapsulation