Discretionary capability confinement

Fong, Philip W. L.

doi:10.1007/s10207-007-0047-5

Cited by 3 publications

(8 citation statements)

References 39 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Fig. 5 enumerates the type constraints of DCC as specified in [12]. We have successfully encoded all the DCC type constraints by an ISOMOD policy, which is displayed in Appendix A.…”

Section: Figure 5 DCC Type Constraintsmentioning

confidence: 99%

“…We demonstrate how ISOMOD can be used for enforcing a general-purpose capability type system, Discretionary Capability Confinement (DCC) [12]. A lightweight, statically enforceable type system, DCC supports the use of abstractly-typed object references as capabilities in a Javalike object-oriented programming language.…”

Section: Discretionary Capability Confinementmentioning

confidence: 99%

“…The focus here is ISOMOD and not DCC. Interested readers may consult [12] for more details of DCC. In DCC, the space of declared types (e.g., class & interface) is partitioned into a finite number of confinement domains, so that every declared type belongs to exactly one confinement domain.…”

Section: Figure 5 DCC Type Constraintsmentioning

confidence: 99%

“…4.2). The ISOMOD policy language is also expressive enough to completely encode a capability type system known as Discretionary Capability Confinement [12] (Sect. 4).…”

Section: Is Interposition (Direct or Irm-based) Always Necessary For mentioning

confidence: 99%

“…Behind the policy of Appendix A is a number of assumptions. As in [12], we assume that domain membership and capability granting policies are embedded in Java classfiles via the JDK 1.5 metadata facility. Domains are represented by specially annotated interfaces, and the dominance and strongly dominance relations are encoded respectively by the subinterfacing relation and JDK 1.5 annotations.…”

Section: Figure 5 DCC Type Constraintsmentioning

confidence: 99%

See 4 more Smart Citations

A Module System for Isolating Untrusted Software Extensions

Fong

Orr

2006

2006 22nd Annual Computer Security Applications Conference (ACSAC'06)

View full text Add to dashboard Cite

show abstract

“…Fig. 5 enumerates the type constraints of DCC as specified in [12]. We have successfully encoded all the DCC type constraints by an ISOMOD policy, which is displayed in Appendix A.…”

Section: Figure 5 DCC Type Constraintsmentioning

confidence: 99%

Section: Discretionary Capability Confinementmentioning

confidence: 99%

Section: Figure 5 DCC Type Constraintsmentioning

confidence: 99%

“…4.2). The ISOMOD policy language is also expressive enough to completely encode a capability type system known as Discretionary Capability Confinement [12] (Sect. 4).…”

Section: Is Interposition (Direct or Irm-based) Always Necessary For mentioning

confidence: 99%

Section: Figure 5 DCC Type Constraintsmentioning

confidence: 99%

See 3 more Smart Citations

A Module System for Isolating Untrusted Software Extensions

Fong

Orr

2006

2006 22nd Annual Computer Security Applications Conference (ACSAC'06)

View full text Add to dashboard Cite

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

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

Discretionary capability confinement

Cited by 3 publications

References 39 publications

A Module System for Isolating Untrusted Software Extensions

A Module System for Isolating Untrusted Software Extensions

Isolating untrusted software extensions by custom scoping rules

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

Contact Info

Product

Resources

About