Protection in programming languages

Abstract

Linguistic mechanisms which can be used to protect one subprogram from another's malfunctioning are described. Function-producing functions and various type-tagging schemes are considered. An attempt is made to distinguish between access limitation and authentication.

Micro-Policies: Formally Verified, Tag-Based Security Monitors

“…As a warm-up, we begin with a simple micro-policy for dynamic sealing [62], [80], a linguistic mechanism analogous to perfect symmetric encryption. Informally, we extend the basic machine with three new primitives (presented as monitor services): mkkey creates a fresh sealing key; seal takes a data value (a machine word) and a key and returns an opaque "sealed value" that can be stored in memory and registers but not used in any other way until it is passed (together with the same key that was used to seal it) through the unseal service, which unwraps it and returns the original raw word.…”

“…Each symbolic micro-policy consists of (i) sets of metadata tags that are used to label every piece of data in the machine's memory and registers (including the program counter); (ii) a transfer function that uses both the current opcode and the tags on the pc, on the current instruction, and on the instruction operands to determine whether the operation is permitted and, if it is, to specify how the pc and the instruction's result should be tagged in the next machine state; and (iii) a set of monitor services that can be invoked by user code. For example, in a micro-policy for dynamic sealing (a languagebased protection mechanism in the style of perfect symmetric encryption [62], described below in §4) the set of tags used for registers and memory might be {Data, Key k, Sealed k}, where Data is used to tag ordinary data values, Sealed k is used to tag values sealed with the key k, and Key k denotes a key that can be used for sealing and unsealing values. The transfer function for this micro-policy would allow, for example, arithmetic operations on values tagged Data but deny them on data tagged Sealed or Key.…”

“…Monitor services are provided to allow user programs to create new keys and to seal and unseal data values with given keys. We instantiate this symbolic machine with a diverse set of security micro-policies: 1) dynamic sealing [62], [80]; 2) compartmentalization, which sandboxes untrusted code and allows it to be run alongside trusted code [84]; 3) control-flow integrity (CFI), which prevents code-reuse attacks such as return-oriented programming [6]; and 4) memory safety, which prevents temporal and spatial violations for heap-allocated data [39]. The intended behavior of each micro-policy is specified by an abstract machine (top layer in Figure 1), which gives a clear characterization of the micro-policy's behavior as seen by a user-level programmer.…”

Paradigm Regained: Abstraction Mechanisms for Access Control

“…The object-capability paradigm, in the air by 1967 [Wilkes79,Fabry74], and well established by 1973 [Redell74,Hewitt73,Morris73,Wulf74,Wulf81], adds the observation that the abstraction mechanisms provided by the base model are not just for procedural, data, and control abstractions, but also for access abstractions, such as Redell's Caretaker. (These are "communications abstractions" in [Tribble95].…”

An Introduction to the Construction and Verification of Alphard Programs

“…(The notion of incorporating protection in languages appears in [2], [26].) In the foregoing discussion we stressed the restrictions imposed on actual parameters by the appearance of the "<>" notation in a formal parameter list.…”