The Oz-E Project: Design Guidelines for a Secure Multiparadigm Programming Language

Abstract

Abstract. The design and implementation of a capability secure multiparadigm language should be guided from its conception by proven principles of secure language design. In this position paper we present the Oz-E project, aimed at building an Oz-like secure language, named in tribute of E [MMF00] and its designers and users who contributed greatly to the ideas presented here. We synthesize the principles for secure language design from the experiences with the capability-secure languages E and the W7-kernel for Scheme 48 [Ree96]. These principles will be used as primary guidelines during the project. We propose a layered structure for Oz-E and discuss some important security concerns, without aiming for completeness at this early stage.

Oz/K

“…In this paper, localities (named "membranes") are finer grained than kells in OZ/K, but they are used only for communication control (confinement), and do not constitute units of failure isolation, or of passivation. The kell construct in OZ/K seems in line with the proposed design guidelines for a secure OZ, presented in [31].…”

A Practical Formal Model for Safety Analysis in Capability-Based Systems

“…Modeling it as a passive subject will be as if it could also store authority, again a very coarse approach. Passive subjects are well fit to model state that is shared between active subjects, but that is not generally useful in capability languages that support some form of concurrency: the practice of (secure) concurrent programming strongly deprecates the use of shared state concurrency [SV05a,VH04,Rei03].…”

“…Instead of setting up an access control policy separated from the functionality of a program, the programmer controls capability propagation by carefully controlling what entities will invoke what other entities and what will be the input and output arguments. This is not always a simple task, but a well designed capability secure programming language can help [SV05a].…”

“…A confused deputy is a deputy that does not know the difference between its own authority and the authority delegated by the client, so that it can be lured into using its own authority on behalf of a faking client. As explained in [Har89,SV05a], capabilities can easily avoid that vulnerability. Scalability: Since references are necessary anyway, combining them with authority does not in the least affect scalability, even as the authority is managed at the finest grained level.…”

“…This is certainly not an easy task. Therefore a real capability secure programming language should have no mechanisms that make this task even harder [SV05a]. But since capabilities are the only mechanism that can actually prevent confused deputy attacks [Har89], the task becomes feasible at last.…”