Discretionary Capability Confinement

Fong, Philip W. L.

doi:10.1007/11863908_9

Cited by 5 publications

(1 citation statement)

References 40 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Likewise, also confined types can be understood using the concept of capabilities that are represented by types (Fong 2005). This idea is further elaborated by Fong in (Fong & Zhang 2004), (Fong 2006), (Fong 2008), and (Fong & Orr 2006). In the first paper, an additional type system is introduced that allows to specify the permitted operations on an object as it is passed from one method to the next.…”

Section: Type-based Securitymentioning

confidence: 94%

Extending the Object-Capability Model with Fine-Grained Type-Based Capabilities.

Wismüller,

Ludwig,

Breitweiser

2024

JOT

View full text Add to dashboard Cite

Although the Principle Of Least Authority (POLA) is a well-recognized guideline for building secure software systems, there is actually a lack of concepts that really encourage programmers to use POLA consequently. The best support for POLA is currently offered by secure languages based on the Object-Capability (OCap) paradigm, where object references serve as capabilities for accessing objects. However, the OCap model just controls the overall accessibility of objects, it does not directly support fine-grained control over the use of specific operations on these objects. While access control at the level of individual methods can be implemented by using the membrane pattern, this approach creates a heavy burden for the programmer, may lead to performance problems, and suffers from the fact that it is difficult to determine the minimum permissions that must be granted.In this paper, we present a type-based split capability model, where the access permissions granted by a reference are restricted by the type of the variables used to send and receive that reference. In this way, required and granted permissions are directly represented in the type definition of a software component's interface. Furthermore, compliance with access restrictions can often be checked statically when a software component is deployed, thus avoiding the run-time overhead of using a membrane.In the case where membranes are needed to enforce access control at run-time, these membranes are automatically built by the run-time system.As a foundation for this model, we specify type checking rules that prevent software components from from amplifying their authority by downcasting a reference to a more permissive type. Finally, we identify the necessary requirements for the run-time system as well as the run-time overhead induced by our security model.

show abstract

Section: Type-based Securitymentioning

confidence: 94%

Extending the Object-Capability Model with Fine-Grained Type-Based Capabilities.

Wismüller,

Ludwig,

Breitweiser

2024

JOT

View full text Add to dashboard Cite

show abstract

Discretionary capability confinement

Fong

2007

Int. J. Inf. Secur.

Self Cite

View full text Add to dashboard Cite

Abstract. Motivated by the need of application-level access control in dynamically extensible systems, this work proposes a static annotation system for modeling capabilies in a Java-like programming language. Unlike previous language-based capability systems, the proposed annotation system can provably enforce capability confinement. This confinement guarantee is leveraged to model a strong form of separation of duty known as hereditary mutual suspicion. The annotation system has been fully implemented in a standard Java Virtual Machine.

show abstract

Isolating untrusted software extensions by custom scoping rules

Fong

Orr

2010

Computer Languages, Systems & Structures

View full text Add to dashboard Cite

In a modern programming language, scoping rules determine the visibility of names in various regions of a program [15]. In this work, we examine the idea of allowing an application developer to customize the scoping rules of its underlying language. We demonstrate that such an ability can serve as the cornerstone of a security architecture for dynamically extensible systems. A run-time module system, ISOMOD, is proposed for the Java platform to facilitate software isolation. A core application may create namespaces dynamically and impose arbitrary name visibility policies (i.e., scoping rules) to control whether a name is visible, to whom it is visible, and in what way it can be accessed. Because ISOMOD exercises name visibility control at load time, loaded code runs at full speed. Furthermore, because ISOMOD access control policies are maintained separately, they evolve independently from core application code. In addition, the ISOMOD policy language provides a declarative means for expressing a very general form of visibility constraints. Not only can the ISOMOD policy language simulate a sizable subset of permissions in the Java 2 security architecture, it does so with policies that are robust to changes in software configurations. The ISOMOD policy language is also expressive enough to completely encode a capability type system known as Discretionary Capability Confinement. In spite of its expressiveness, the ISOMOD policy language admits an efficient implementation strategy. Name visibility control in the style of ISOMOD is therefore a lightweight access control mechanism for Java-style language environments.

show abstract

Discretionary Capability Confinement

Cited by 5 publications

References 40 publications

Extending the Object-Capability Model with Fine-Grained Type-Based Capabilities.

Extending the Object-Capability Model with Fine-Grained Type-Based Capabilities.

Discretionary capability confinement

Isolating untrusted software extensions by custom scoping rules

Contact Info

Product

Resources

About