Chaperones and impersonators

Stephen, S.-T. Yau; Tobin-HochstadtSam,; Bruce, FindlerRobert; FlattMatthew,

doi:10.1145/2398857.2384685

Cited by 9 publications

(4 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For specifications on objects (Strickland and Felleisen 2010), structures (Strickland et al 2012) or closures , the cost of checking contracts is non-local. The contract system defers checking until methods are called or fields are accessed, which happens after crossing the contract boundary.…”

Section: Contractsmentioning

confidence: 99%

Compiler Construction

2015

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Section: Contractsmentioning

confidence: 99%

Compiler Construction

2015

Lecture Notes in Computer Science

View full text Add to dashboard Cite

“…Object-capability-safe languages typically already have constructs that achieve complete and transparent mediation and interposition, e.g., membranes [10] in E and Caja. Recent research [7] explores the addition of such a feature to existing languages, and contract systems have been implemented using membrane-like constructs [19,31]. In addition, membranes have been used to equip Javascript objects with contracts for path-based access control for method invocation [32].…”

Section: B Implementing Capability Controlmentioning

confidence: 99%

Declarative Policies for Capability Control

Dimoulas

Moore

Askarov

et al. 2014

2014 IEEE 27th Computer Security Foundations Symposium

View full text Add to dashboard Cite

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.

show abstract

“…While contracts for first-order values and methods require little support from the programming language or its implementation, higher-order contracts force language designers to think of contract specifications as borderlines between two parties [28].…”

Section: Racket Contracts a Refreshermentioning

confidence: 99%

“…Once contracted values have passed the tester's examination, the option contract wrapper-technically, a proxy value [28]-no longer checks any properties. Instead, it transparently stores the underlying contract with the value for future use, leaving dep-lexer/c inactive for now.…”

Section: Exercising and Waiving Optionsmentioning

confidence: 99%

Option contracts

Dimoulas

Findler

Felleisen

2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

Self Cite

View full text Add to dashboard Cite

Many languages support behavioral software contracts so that programmers can describe a component's obligations and promises via logical assertions in its interface. The contract system monitors program execution, checks whether the assertions hold, and, if not, blames the guilty component. Pinning down the violator gets the debugging process started in the right direction. Quality contracts impose a serious runtime cost, however, and programmers therefore compromise in many ways. Some turn off contracts for deployment, but then contracts and code quickly get out of sync during maintenance. Others test contracts randomly or probabilistically. In all cases, programmers have to cope with lack of blame information when the program eventually fails.In response, we propose option contracts as an addition to the contract tool box. Our key insight is that in ordinary contract systems, server components impose their contract on client components, giving them no choice whether to trust the server's promises or check them. With option contracts, server components may choose to tag a contract as an option and clients may choose to exercise the option or accept it, in which case they also shoulder some responsibility. We show that option contracts permit programmers to specify flexible checking policies, that their cost is reasonable, and that they satisfy a complete monitoring theorem.

show abstract

Chaperones and impersonators

Cited by 9 publications

References 28 publications

Compiler Construction

Compiler Construction

Declarative Policies for Capability Control

Option contracts

Contact Info

Product

Resources

About