Object-Capability as a Means of Permission and Authority in Software Systems

by   Jörn Koepe, et al.
Universität Paderborn

The object-capability model is a security measure that consists in encoding access rights in individual objects to restrict its interactions with other objects. Since its introduction in 2013, different approaches to object-capability have been formalized and implemented. In this paper, we present the object-capability model, and present and discuss the state-of-the-art research in the area. In the end, we conclude, that object capabilities can help in increasing the security of software, although this concept is not widely spread.



There are no comments yet.


page 1


The Sierpinski Object in the Scott Realizability Topos

We study the Sierpinski Object in the Scott Realizability Topos....

Dynamic Information Security Management Capability: Strategising for Organisational Performance

The increasing frequency, impact, consequence and sophistication of cybe...

FRAMER: A Cache-friendly Software-based Capability Model

Fine-grained memory protection for C and C++ programs must track individ...

Predictable universally unique identification of sequential events on complex objects

Universal identifiers and hashing have been widely adopted in computer s...

Uninitialized Capabilities

This technical report describes a new extension to capability machines. ...

Intentional Forgetting

Many damaging cybersecurity attacks are enabled when an attacker can acc...

A study on the Morris Worm

The Morris worm was one of the first worms spread via the internet. It w...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Nowadays, many applications rely on external libraries to function correctly. However, including third-party libraries also opens an attack surface. Not all third-party programs are trustful or secure. A means to reduce security risks is to introduce access-control mechanisms, such as the object-capability model, introduced by Mark Miller in his doctoral dissertation (Miller, 2006).

In the object-capability model, which is designed for object-oriented languages, objects are used to manage access control. Specific objects can only access the behaviour they need, if they have a direct reference to the object providing that behaviour, following the terms of authority and permission. Those terms are used to model the access control, with permission being the right to invoke certain behaviour on the targeted object, while authority describes the ability to cause effects on an object (Drossopoulou et al., 2016).

In the past few years, new research was conducted on different areas of object-capabilities. Some focus on the formalism of the model (Drossopoulou et al., 2016), while others concentrate on analyzing security properties in that system (Murray, 2010). Another common research topic is the study of typical problems of object-capabilities (Drossopoulou and Noble, 2013, 2014). Although capability safety was proven to imply authority safety (Maffeis et al., 2010), the formal characterization of object capabilities is not sufficient for verifying an application (Devriese et al., 2016). Nonetheless, it is possible to check for violations of object-capabilities with the help of model checking (Rhodes et al., 2014).

In this paper, we explain the concept of object-capability model, along with background information on related topics such as access control, authority, and permission. We then detail recent publications on object-capability, first looking at papers that focus on the formal aspect of object-capability, like introducing and analyzing different concepts of object-capability. Second, we present papers which focus on the implementation of object-capabilities and the advantages of the model for applications at a whole. Finally, the last category we explore includes papers that take a different approach to object-capability, for example, by analysing the corresponding model (Drossopoulou and Noble, 2014) or how to automatically check for flaws in the model with the help of a model checker (Rhodes et al., 2014). In the last part of the paper, we summarize the current state of the object-capability model, and discuss open questions on the topic.

2. The Object-Capability Model

In this section, we explain the object-capability model, and the notions of authority and permission.

2.1. Object-Capabilities

The object-capability model was introduced by Mark Miller in his doctoral thesis in 2006 (Miller, 2006). This security model is used to control accesses to particular parts of a program, in order to restrict potential malicious behaviour. A capability is defined as a token that describes access-rights, and object-capabilities as capabilities applied to object-oriented languages. In the object-capability model, this token is thus a reference to a specific object. An object can only interact with another object if it has the capability for the specific object. The example shown in Listing 1 and Figure 1 shows a simple implementation of the model.

2    B B = new B()
3    A A = new A(B) //  A -> B
4    C C = new C()
5    A.B.doSomething()
8A {
9    B;
10    D:
11    new A(B){
12        B = B
13        D = new D() // A -> D
14    }
Listing 1: Simple example for object-capabilities.




Figure 1. Object-capabilities from Listing 1. Edges represent references between the different objects of the program.

The object-oriented program in Listing 1 contains three objects: A, B, and C. A receives a reference to B in its constructor, while B and C do not get any references. Following the object-capability model, A is allowed to call methods on B, while the other two objects can only use their own methods. In addition, A also has a reference to D, since it creates the object. References are encoded in a reference graph, which also represents the given capabilities. The reference graph for Listing 1 is shown in Figure 1.

Note that no matter at which point of the program execution the capability is created, the capability is valid over the entire execution, and the object owning a reference to another can invoke behaviour on that latter object. There are multiple ways to gain capabilities for an object:

  • The easiest one is to create a new instance of the desired object. By creating the object the creator object receives the reference and therefore the capability for the created object. In the example in Listing 1 this happens for A and D, where the former gets a reference to the later by creating it.

  • It is also possible to introduce objects to one another. In the example, A could have introduced B to C or the other way around.

  • Another way to get a capability is to be born with it. This is also shown in the example, with A being constructed with a direct reference to B.

2.1.1. Capability-safety

A language is capability-safe with respect to object-capability if it is restricted in a way that enforces the object-capability model. The most important restriction is that there should be no globally accessible mutable states (Devriese et al., 2016). This restriction enforces all communication between objects to be done over the capabilities. Many common object-oriented languages, such as Java, can be used in a capability-safe way if these restrictions are met in the whole program. In the case of Java, this means not using static variables, since they are shared between all instances of a class.

2.2. Authority and Permission

The notions of authority and permission are broadly used to discuss the properties of the object-capability model. These terms were first introduced informally by Mark Miller along the object-capability model itself (Miller, 2006). He formalized them later together with Drossopoulou et al. (Drossopoulou et al., 2016).

To argue about permission and authority on a formal level, we first introduce notations for program states, following Drossopoulou et al.’s paper (Drossopoulou et al., 2016).

2.2.1. Background

In the following, we assume a capability-safe language, i.e., we assume no global variables and that the behaviour of an object can only be called if the caller has the reference to the specific object. We also assume a small step operational semantic, meaning that only one computation step can be executed at a time, which we formalize as follows:

where is the state of the program at runtime, and are statements of the program. is either a new statement or result. For example, for the Null state, any number or object can be a result. An example language that fits the requirements as well as the definitions for the states, is detailed in Drossopoulou et al.’s paper (Drossopoulou et al., 2016).

is called the liberal execution, and describes every possible program execution. In other words, it is the set of every possible computation sequence starting in and resulting in .

Moving on to the operational semantics, the behaviour of the program is modelled in a similar way. We define the behavioural description , such that

where ensures that the liberal execution holds. This description corresponds to a large range of behaviour such as low-level mechanisms or policy specifications (Drossopoulou et al., 2016).

Since all executions of a program are characterized by , then also characterizes the program, which leads to the following definition:

Definition 2.1 ().

The definition, the small step operational semantic, the liberal execution, and the behavioural description allow us to construct three so-called future worlds, which describe how the program will look like in the next state. These worlds, called the Eventual World (EW), the Behaviour World (BW), and the Maximal World (MW), are defined as follows:

Definition 2.2 ().

As stated in the Definition 2.2, EWs are reachable by a program, BWs are created following a behavioural description, and MWs are created by the liberal execution. With these definitions, Drossopoulou et al. derive the following inclusions:

Lemma 2.3 ().

program , behavioural description and state :

The full proof is found in Drossopoulou et al.’s paper (Drossopoulou et al., 2016).

2.2.2. Permission

The concept of permission is described as the right to access an object directly and invoke its behaviour (Miller, 2006; Drossopoulou et al., 2016). With the definitions of the worlds, it is possible to create four different types of permission.

The first permission type is the base permission called Current Permission (CP).

Definition 2.4 ().

Where is an object. The base permission states that if a subject has a direct access right to the object, it can invoke its behaviour. is a receiver of a currently executed method.

With the base permission, it is possible to define the three other types of permissions: the Eventual Permission (EP), the Behaviour Permission (BP), and the Maximal Permission (MP):

Definition 2.5 ().

EP are the permissions that are eventually created by a program , BP are those created by a behavioural description and MP are those created by liberal executions.

Since the permissions are derived from the definition of worlds, we derive the following lemma:

Lemma 2.6 ().

program , behavioural description , and state :

2.2.3. Authority

In contrast to permission, authority describes the possibility to invoke behaviour on an object with out a direct link. Similarly to permission, we can define four types of authority: the base Current Authority (CA), the Eventual Authority (EA), the Behaviour Authority (BA), and the Maximal Authority (MA).

Definition 2.7 ().

With this definition, the CA(o) permission contains every object which might be altered by calling a method. This means that the authority has the ability to modify an object. In this case, the subject does not need to have a direct permission to the object to be altered, as it can happen over other method calls. Like for permissions, the following holds:

Lemma 2.8 ().

program , behavioural description , and state :

With these definitions, it is possible for an object to have authority but not permission over another object, and vice versa. We illustrate this in the example in Listing 2 and Figure 2.

1class A(){
2    int x;
5class B(){
6    A a
7    B(A a) { this.a = a; }  // b --> a
8    inc() { a.x ++; }
11class C() extends B{
12    inc(){};
15class D(){
16    B b;
17    D(B b){ this.b = b; } // d --> b
18    inc(){ b.inc(); }
22    a = new A();
23    b = new B(a); // b -> a
24    c = new C(a); // c -> a
25    d = new D(b); // d -> b
Listing 2: Example program for authority and permission.




Figure 2. Access path from Listing 2. Solid lines are indicate permissions, dashed lines indicate authority.

As shown in the graph, b has permission and authority over a, since it has a direct reference to it and also can modify a. On the other hand, c can not modify a, as it does have authority over it. It has therefore no authority over a, although it has the permission on it. Finally, d can modify a without knowing it directly: by calling the increase() method from b, which in turn modifies a. So, d has authority over a, but no permission.

3. Past Research on Object-Capability Approaches

In this section, we detail past research on the topic of object-capability. We first present papers focusing on formalization, then on implementation, and finally, on the papers that do not fit well into the those sections.

3.1. Formal Aspect of Object-Capability

Many papers address the formalization of the object-capability model, with the goal of proving particular security properties with the help of object-capability.

In 2003, Miller et al. (Miller et al., 2003) presented common myths on the topic of capabilities in their paper“Capability Myths Demolished” (Miller et al., 2003). In their paper, they address three myths: the equivalence myth, the irrevocability myth and the confinement myth, which result form different interpretations of capability. The first myth states that access-control list systems and capability systems are equivalent, and the second, that capability-based access cannot be revoked. The last myth states that a capability system is not able to enforce confinement. Miller et al. demonstrate that the three myths only hold for intermediate security models, but not for the pure capability model, or the object-capability model.

One of the most influential publications on the topic of object-capability is Mark Miller’s doctoral thesis, called ”Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control"  (Miller, 2006). The thesis introduces the object-capability model, and the core terms of authority and permission. Therefore this thesis can be considered as the foundation of object-capability. Miller developed these concepts on the basis of the already existing concept of capabilities and extended it to objects.

Another influential paper is “Permission and Authority Revisited towards a formalisation” (Drossopoulou et al., 2016) by Drossopoulou et al. In this paper, the concepts of authority, permission, and object-capability are extended and fully formalized, as this was left out in Miller’s thesis.

Maffeis et al. show that capability safety implies authority safety in the paper“Object Capabilities and Isolation of Untrusted Web Applications” (Maffeis et al., 2010). Authority safety is defined with two properties: first, an object can only influence the authority of an object whose authority influences its own authority. Second, the change of authority for an object is bounded by the authority of the acting object. These properties are enough to ensure isolation and, as a result, can be used to isolate untrusted code.

In 2010, Murray promoted the construction of patterns to enforce security properties in his thesis “Analysing Security Properties of Object-Capabilities” (Murray, 2010). To describe a pattern, he uses Communicating Sequential Processes (CSP) and analyzes it with the help of a refinement-checker. In his thesis, Murray shows that it is possible to not only describe the properties of object-capabilities with CSP, but also the capabilities themselves. It is thus possible to reason about a CSP model for object-capability as a substitution for the real system, making it easier to prove the properties of the system.

Devriese, Birkedal and Pessens focus on the formal characterization of object-capabilities in their paper “Reasoning about Object Capabilities with Logical Relations and Effect Parametricity” (Devriese et al., 2016). In this paper, they show that existing formal characterizations do not capture capability safety, and therefore it is not sufficient for verifying application security. To address this problem, they introduced a relation that helps to deliver a better characterization.

The paper “Capabilities for Uniqueness and Borrowing” by Haller and Odersky (Haller and Odersky, 2010) states that it is important for a system of unique objects to send messages over references, but the message is restricted due to the ill-effects of aliases. To solve the aliasing problem, they introduce a new type of uniqueness based on capabilities. This uniqueness enforces an at-most-one consumption of references and a notion of flexibility. To show that the new uniqueness is sound, the authors implemented and verified their approach through a simple example.

Swasey et al. introduce a logic called Object Capability Pattern Logic (OCPL), to describe object-capabilities in their paper “Robust and Compositional Verification of Object Capability Pattern” (Swasey et al., 2017). Their logic, makes it easier to prove the robustness of programs.

The paper “On Access Control, Capabilities, Their Equivalence and Confused Deputy Attacks” by Rahani, Garg, and Rezk (Rajani et al., 2016) addresses the differences between access control, and capabilities and states, and argue that that the two notions are fundamentally different. Furthermore, they prove that it is not possible for capabilities to prevent all attacks, and therefore a capability-based system cannot be fully secure.

3.2. Implementational Aspect of Object-Capability

A large share of the related work also presents how to implement object-capability or how to ease their implementation.

Drossopoulou et al. present “The Need for Capability Policies” (Drossopoulou and Noble, 2013) and “How to Break the Bank: Semantics of Capability Policies” (Drossopoulou and Noble, 2014). Both papers state that since the policies for object-capability are mostly only implicitly given, the code for the capabilities is often tangled with the main program code. The solution they propose is to make the policies explicit, with the programmer specifying their expectations about the security properties of the program. In the first paper (Drossopoulou and Noble, 2013), the authors state that this system would make it easier to reason about the explicit policies, and to check them for flaws. In addition, the second paper (Drossopoulou and Noble, 2014) states that a structured specification is needed to express the policies and started designing such a specification (Drossopoulou and Noble, 2014).

Another approach regarding the implementation of object-capability was presented by Darya Mellicher in her thesis proposal “Controlling Module Authority via Programming Language Design” (Melicher, 2018). This approach proposes the use of a capability safe module system for access-control. In the proposal, Mellicher draws a first draft for such a system, which she and her co-authors also present in the paper “A Capability-Based Module System for Authority Control" (Melicher et al., 2017). In this module system, each module is a statically typed capability.

3.3. Other Focuses

We now present the papers which use object-capability or propose similar approaches.

“Swapsies on the Internet” (Drossopoulou et al., 2015a) and “Reasoning about Risk and Trust in an Open World’ (Drossopoulou et al., 2015b), both published by Drossopoulou et al. define the concept of risk and trust, and base their examples on top of the object-capability model . For those examples, the authors prove that the specifications for risk and trust are fulfilled.

An approach similar to object-capabilities is denied capabilities, published in the paper “Deny Capabilities for Safe, Fast Actors” by Clebsch et al. (Clebsch et al., 2015). This model introduces a flexible type system, which can be used to deny control, in a similar system to access control.

The paper “Minimal Ownership for Active Objects” by Clarke et al (Clarke et al., 2008) states that it is natural for object-oriented languages to use active objects as an approach to concurrency. Active objects consist of an unshared state and a thread for control. The data sharing should only be done by references, but this leads to aliasing problems. To counter these problems, the authors prove that it is possible to pass objects belonging to one active object to another active object without copying the state. Although this paper does not deal with object-capabilities per se, the concept of data sharing over references is quite similar.

The last approach to object-capability is a model checker published in “Dynamic Detection of Object Capability Violations Through Model Checking” by Rhodes et al. (Rhodes et al., 2014). With the help of their model checker, the authors allow the visualization of leaks in a system.

4. Discussion and Conclusion

Through the large body of research conducted on the topic, we see that object-capability has the potential to improve the security of distributed programs. However, even if the potential for security is there, it is not widely used, mostly due to convenience. Global and static variables–which break the requirements for the object-capability model–are commonly used, especially for short scripts. Excluding their use from the beginning of a project could be an efficient solution.

Most publications on the topic of object-capability focus on the formal properties of the model, introducing extensions to the base model, analyzing its properties, or describing analysis methods. Current research agrees on the security of object-capability, although restrictions to the model are required, in some cases.

Other publications focus on implementation approaches to object-capabilities. The main two approaches are to make the policies for the model explicit (requiring a different program design to divide the code between object-capabilities and program behaviour), and to include object-capability modules directly in the programming language. This last approach is fairly new and only proposes early concepts for such a programming language.

Since the object-capability model is not included in most object-oriented languages, future work to encourage its adoption could be possible to provide a library of universal patterns. With the help of such patterns, software developers could implement the model in most object-oriented programming languages. This approach would require the developer to know about the model and the patterns, which could be achieved by including documentation in the style guides of the target programming languages.

All in all, object-capability has a high potential for enhancing software security. However knowledge about this technique is not widespread and object-capability is therefore rarely used. We encourage researchers and practitioners to spread the word about the potential of the object-capability model, and aim to include it into style guides and pattern lists.

This research was conducted under the supervision of Ben Hermann as part of the Secure Systems Engineering seminar at Paderborn University, organized by Eric Bodden and Lisa Nguyen Quang Do. It was partially funded by the Heinz Nixdorf Foundation.


  • (1)
  • Clarke et al. (2008) Dave Clarke, Tobias Wrigstad, Johan Östlund, and Einar Broch Johnsen. 2008. Minimal Ownership for Active Objects. In Programming Languages and Systems, G. Ramalingam (Ed.). Vol. 5356. Springer Berlin Heidelberg, Berlin, Heidelberg, 139–154. https://doi.org/10.1007/978-3-540-89330-1_11 bibtex:ramalingam_2008.
  • Clebsch et al. (2015) Sylvan Clebsch, Sophia Drossopoulou, Sebastian Blessing, and Andy McNeil. 2015. Deny capabilities for safe, fast actors. In Proceedings of the 5th International Workshop on Programming Based on Actors, Agents, and Decentralized Control - AGERE! 2015. ACM Press, Pittsburgh, PA, USA, 1–12. https://doi.org/10.1145/2824815.2824816
  • Devriese et al. (2016) Dominique Devriese, Lars Birkedal, and Frank Piessens. 2016. Reasoning about Object Capabilities with Logical Relations and Effect Parametricity. In 2016 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, Saarbrucken, 147–162. https://doi.org/10.1109/EuroSP.2016.22
  • Drossopoulou and Noble (2013) Sophia Drossopoulou and James Noble. 2013. The need for capability policies. In Proceedings of the 15th Workshop on Formal Techniques for Java-like Programs - FTfJP ’13. ACM Press, Montpellier, France, 1–7. https://doi.org/10.1145/2489804.2489811
  • Drossopoulou and Noble (2014) Sophia Drossopoulou and James Noble. 2014. How to Break the Bank: Semantics of Capability Policies. In Integrated Formal Methods, Elvira Albert and Emil Sekerinski (Eds.). Vol. 8739. Springer International Publishing, Cham, 18–35. https://doi.org/10.1007/978-3-319-10181-1_2
  • Drossopoulou et al. (2015a) Sophia Drossopoulou, James Noble, and Mark S. Miller. 2015a. Swapsies on the Internet: First Steps Towards Reasoning About Risk and Trust in an Open World. In Proceedings of the 10th ACM Workshop on Programming Languages and Analysis for Security (PLAS’15). ACM, New York, NY, USA, 2–15. https://doi.org/10.1145/2786558.2786564
  • Drossopoulou et al. (2015b) Sophia Drossopoulou, James Noble, Mark S Miller, and Toby Murray. 2015b. Reasoning about Risk and Trust in an Open Word. (2015), 34.
  • Drossopoulou et al. (2016) Sophia Drossopoulou, James Noble, Mark S. Miller, and Toby Murray. 2016. Permission and Authority Revisited towards a formalisation. In Proceedings of the 18th Workshop on Formal Techniques for Java-like Programs - FTfJP’16. ACM Press, Rome, Italy, 1–6. https://doi.org/10.1145/2955811.2955821
  • Haller and Odersky (2010) Philipp Haller and Martin Odersky. 2010. Capabilities for Uniqueness and Borrowing. In ECOOP 2010 – Object-Oriented Programming (Lecture Notes in Computer Science), Theo D’Hondt (Ed.). Springer Berlin Heidelberg, 354–378.
  • Maffeis et al. (2010) Sergio Maffeis, John C. Mitchell, and Ankur Taly. 2010. Object Capabilities and Isolation of Untrusted Web Applications. In 2010 IEEE Symposium on Security and Privacy. IEEE, Oakland, CA, USA, 125–140. https://doi.org/10.1109/SP.2010.16
  • Melicher (2018) Darya Melicher. 2018. Controlling Module Authority via Programming Language Design. (2018), 24.
  • Melicher et al. (2017) Darya Melicher, Yangqingwei Shi, Alex Potanin, and Jonathan Aldrich. 2017. A Capability-Based Module System for Authority Control. In 31st European Conference on Object-Oriented Programming (ECOOP 2017) (Leibniz International Proceedings in Informatics (LIPIcs)), Peter Müller (Ed.), Vol. 74. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, 20:1–20:27. https://doi.org/10.4230/LIPIcs.ECOOP.2017.20
  • Miller (2006) Mark Samuel Miller. 2006. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control. PhD Thesis. Johns Hopkins University, Baltimore, Maryland, USA.
  • Miller et al. (2003) Mark S Miller, Ka-Ping Yee, and Jonathan Shapiro. 2003. Capability Myths Demolished. (2003), 15.
  • Murray (2010) Toby Murray. 2010. Analysing the Security Properties of Object-Capability Patterns. (2010), 239.
  • Rajani et al. (2016) V. Rajani, D. Garg, and T. Rezk. 2016. On Access Control, Capabilities, Their Equivalence, and Confused Deputy Attacks. In 2016 IEEE 29th Computer Security Foundations Symposium (CSF). 150–163. https://doi.org/10.1109/CSF.2016.18
  • Rhodes et al. (2014) Dustin Rhodes, Tim Disney, and Cormac Flanagan. 2014. Dynamic Detection of Object Capability Violations Through Model Checking. In Proceedings of the 10th ACM Symposium on Dynamic Languages (DLS ’14). ACM, New York, NY, USA, 103–112. https://doi.org/10.1145/2661088.2661099
  • Swasey et al. (2017) David Swasey, Deepak Garg, and Derek Dreyer. 2017. Robust and Compositional Verification of Object Capability Patterns. Proc. ACM Program. Lang. 1, OOPSLA (Oct. 2017), 89:1–89:26. https://doi.org/10.1145/3133913