Non-delegatable authorities in capability systems

Abstract

We present a novel technique, known as the non-delegatable authority (NDA), for distributing authority to unconfined subjects in capability systems that prevents them from sharing the exact same authority that they have been given with anyone else. This feature is present in common systems based on access control lists (ACLs) in which one may hand out a permission without handing out the associated "grant" right, but has been thought to be impossible to express in capability systems until now. Consequently, we demonstrate that NDAs may be used to express ACL-like constructs and their basic pattern is directly applicable for implementing Multi-Level Security and identity-based access controls in the object-capability model.The extra complexity introduced by our NDA implementation can be hidden behind constructs that allow NDAs to be wielded as if they were ordinary capabilities to the target resource. These constructs cannot break the non-delegatability constraint and allow NDAs to be used effectively, although with less efficiency than delegatable authorities.

COAST: An Architectural Style for Decentralized On-Demand Tailored Services

“…A capability [40], fuses access to, and designation of, a protected resource into a single, unforgeable reference. The object capability security model [28] implements confinement [30], revocation, and multi-level security [41]; offers patterns for non-delegation [42]; resolves the problem of the Confused Deputy [43], [44]; and is a base mechanism for information flow control [45], [46]. The Emerald language [47] is an early example of an object capability language.…”

Communication and Capability URLs in COAST-based Decentralized Services

“…A capability [13], fuses access to, and designation of, a protected resource into a single, unforgeable reference. The object capability security model [36] implements confinement [46], revocation, and multilevel security [37]; offers patterns for non-delegation [39]; resolves the problem of the Confused Deputy [12,28]; and is a base mechanism for information flow control [6,38]. The Emerald language [43] is an early example of an object-capability language.…”

An Overview of the Annex System

“…Another perceived weakness of capability systems is a perceived lack of support for mandatory security policies [26]. Recent research is beginning to show, however, that these concerns may not be too burdensome if an appropriate capability model is used [18,20,23]. …”

“…Although the details of our implementation are beyond the scope of this paper, we used the following basic approach: (1) the router's initial traffic filtering policies completely firewall all newly connected clients from sending or receiving any traffic, other than to the MiniSec device controlling the router; (2) the router control object would cause the broadcast of an authentication beacon containing a weakly permissive capability for itself to any potential MiniSec clients that have roamed onto the network, thus allowing them to initiate capability-based authentication with the Brick; (3) this new client would address the router control object using the beacon capability and attach a capability to a credential object proving that it is cleared to the appropriate level (see [20] for more details about this step); and (4) the router control object would modify the router's traffic-filtering rules allowing the newly authenticated MiniSec device to access the network.…”