Declarative Policies for Capability Control

Abstract

In capability-safe languages, components can access a resource only if they possess a capability for that resource. As a result, a programmer can prevent an untrusted component from accessing a sensitive resource by ensuring that the component never acquires the corresponding capability. In order to reason about which components may use a sensitive resource it is necessary to reason about how capabilities propagate through a system. This may be difficult, or, in the case of dynamically composed code, impossible to do before running the system. To counter this situation, we propose extensions to capabilitysafe languages that restrict the use of capabilities according to declarative policies. We introduce two independently useful semantic security policies to regulate capabilities and describe language-based mechanisms that enforce them. Access control policies restrict which components may use a capability and are enforced using higher-order contracts. Integrity policies restrict which components may influence (directly or indirectly) the use of a capability and are enforced using an information-flow type system. Finally, we describe how programmers can dynamically and soundly combine components that enforce access control or integrity policies with components that enforce different policies or even no policy at all.

Reasoning about Object Capabilities with Logical Relations and Effect Parametricity

“…They prove a property related to one of the properties in Section 5, which also ignores the behaviour of processes/objects. Dimoulas et al formalise capability safety in terms of a notion of component boundaries and the ownership of code by security principals [24], in a simple language without mutable state. The formalisation of capability-safety does not seem intended for reasoning about code.…”

Swapsies on the Internet

“…Lerner et al extend this system to ensure browser extensions observe "private mode" browsing conventions, such as that "no private browsing history retained" [22]. Dimoulas et al [11] generalise the language and type checker based approach to enforce explicit policies, that describe which components may access, or may influence the use of, particular capabilities. Alternatively, Taly et al [39] model JavaScript APIs in Datalog, and then carry out a Datalog search for an "attacker" from the set of all valid API calls.…”

“…The specification consists of two policies: Pol_deal_1 promises that if the purses come from the same mints, and have sufficient funds (lines 6-7), then the result will be true (line 9), the transfer of the monies and the goods will take place (lines [10][11], and all other purses will remain unaffected (line 12). Pol_deal_2 promises that if the purses do not come from the same mints, or have insufficient funds, then the result will be false and all purses will be unaffected.…”

Extensible access control with authorization contracts

“…Moore et al [29] use contracts to constrain the use of capabilities in a secure shell scripting language. Dimoulas et al [10] use contracts to control the flow of capabilities between components in objectcapability languages. Heidegger et al [19] use contracts to specify which fields of an object may be accessed by a component.…”