Extensible Access Control with Authorization Contracts Scott Moore Christos Dimoulas Robert Bruce Findler Harvard University (USA) Harvard University (USA) Northwestern University (USA) [email protected] [email protected] [email protected] Matthew Flatt Stephen Chong University of Utah (USA) Harvard University (USA) mfl[email protected] [email protected] Abstract For example, Unix file permissions describe which users Existing programming language access control frameworks are allowed to call which operations on a file. The access do not meet the needs of all software components. We propose control mechanism uses file permissions to determine what an expressive framework for implementing access control rights are necessary to call different sensitive operations. Each monitors for components. The basis of the framework is Unix process executes on behalf of a specific user, and a a novel concept: the authority environment. An authority request to call an operation possesses the same rights as environment associates rights with an execution context. The the user of the process that issues the request. Thus, file building blocks of access control monitors in our framework permissions answer the first question, and the rights of the are authorization contracts: software contracts that manage user associated with a process answer the second question. authority environments. We demonstrate the expressiveness Importantly, Unix associates users and processes in two of our framework by implementing a diverse set of existing different ways. By default, a new process runs on behalf access control mechanisms and writing custom access control of the same user as the process that spawned it. But a process monitors for three realistic case studies. can run on behalf of a different user if it runs an executable that has the setuid bit set. When a process invokes a setuid Categories and Subject Descriptors D.3.1 [PROGRAM- executable, the operating system launches a new process MING LANGUAGES]: Formal Definitions and Theory— to run the executable and associates the new process with Semantics; D.2.4 [SOFTWARE ENGINEERING]: Software/ the user that owns the executable, rather than the user that Program Verification—Programming by contract invoked it. Hence, this feature creates services that provide restricted access to resources that an invoking user could not Keywords access control; contracts; authorization logic otherwise access. Similar to operating systems, software components also 1. Introduction need access control mechanisms to prevent unauthorized An access control monitor mediates requests to call sensitive clients from calling sensitive operations while allowing au- operations and allows each call if and only if the request thorized ones to do so. Thus, when responding to a request possesses the necessary rights to call the operation. Broadly to call a sensitive operation, access control mechanisms for speaking, when an access control mechanism is presented components must be able to answer the same two questions: with a call to a sensitive operation, it must be able to answer which rights are necessary for the call and which rights the two questions. First, which rights are required for the call? request possesses. And second, which rights does the request possess? The However, access control needs of components vary, and design of an access control mechanism specifies, implicitly it is impossible to choose a single answer to these questions or explicitly, the answers to these questions. that satisfies all component authors. To make things worse, access control mechanisms for general purpose programming languages have made design choices that are not suitable for all application domains and are typically mutually incom- patible. For example, Java stack inspection [40] determines the rights associated with a call site by walking the stack from the current stack frame. In contrast, object-capability languages (e.g., E [25] and Caja [26]) determine rights by the Appeared in OOPSLA 2016 lexical structure of the program: a code may call operations We have used the framework to implement diverse access on exactly those resources that are reachable from variables control mechanisms: discretionary access control, stack in- in the code’s text. spection, history-based access control, and object-capabilities (§4). We demonstrate the practicality of our approach with In this paper we propose a new, extensible access control three realistic case studies (§5). framework that allows component authors to design access control monitors that suit their needs. The framework sup- 2. Authority Environments ports the design and implementation of many different novel In this section, we introduce authority environments as a and existing access control monitors for software compo- unifying concept for access control. First, we review the nents. Moreover, because different monitors are implemented differences between lexical and dynamic scoping (§2.1). Then using a common framework, different software components we describe the connection between lexical and dynamic within the same application can use different access control scoping and access control (§2.2) and show how we can mechanisms. use scoping in the design of a framework for writing access The framework builds on a novel concept: the authority control monitors (§2.3). Throughout, we use small examples environment. Just as each execution context has a variable in the Racket programming language [16]. environment that maps variable identifiers to values, each ex- ecution context has an authority environment that associates 2.1 Lexical and Dynamic Scoping the context with its rights to call operations. The rights that a The scope of a variable binding is the spatial and temporal call to a sensitive operation possesses are those possessed by part of the program in which it is visible. A common way to the authority environment of the call’s execution context. categorize strategies for assigning scopes to bindings is as By analogy with dynamic and lexical scoping of variable either lexical or dynamic. Earlier work distinguishes between environments, we identify two ways in which an execution the scope of a binding, which describes where the binding context can receive authority: is visible in the program text, and the extent of a binding, 1. dynamically, by inheriting the authority environment of which describes when the binding is visible during execution. the surrounding execution context, and Dynamic scope often refers to bindings that have dynamic 2. lexically, by capturing the authority environment of the extent and “indefinite” scope. Here, we use dynamic scope to execution context where it is defined. refer to bindings that have dynamic extent and lexical scope, Returning to the Unix file system example, a process receives also called “fluid” scope [17, 34, 35]. authority dynamically when it inherits the user of the process Under lexical scoping, a variable refers to the binding that launched it. A process receives authority “lexically” from its closest binder in the textual structure of the program. when it runs a setuid executable. For example, in the Racket expression below, the variable Based on the correspondence with variable scoping, we x in function f refers to the binding in the outer-most let define a framework for designing access control monitors statement. The evaluation of this expression returns 0 since as sets of monitor actions that manipulate authority environ- the inner-most let statement has no effect on the value x ments (§3). We implement our framework as a library for binds within f. Racket [16] without changes to the language’s runtime. We (let ([x 0]) use higher-order contracts [15] to specify where an access (let ([f ( lambda () x)]) control monitor should interpose on a program and how it (let ([x 42]) should manage authority environments. Contracts are exe- (f)))) cutable specifications attached to software components that support separation of concerns by removing defensive checks In a programming language with fluid scoping, program- from code implementing functionality [22–24]. In the same mers can instead associate a binding with the dynamic extent way, our authorization contracts separate the task of access of an expression. That binding is visible to any code that runs control from the program’s functionality. in the dynamic extent of the expression. For example, the The design of this framework presents four major contri- following Racket expression defines a new fluidly-scoped butions: variable x with default value 0. The parameterize expression 1. the introduction of authority environments as a unifying binds x to the value 42 in the dynamic extent of its body. The concept for access control mechanisms (§2), variable x in the body of f refers to the most recent bind- 2. the introduction of context contracts to check and enforce ing rather than the closest one in the program text. Since f properties of execution contexts (§3.1), is invoked within the parameterize expression, the program 3. a novel authorization logic for representing and querying evaluates to 42 instead of 0. authority in authority environments (§3.2), and (let ([x ( make-parameter 0) ]) 4. authorization contracts that specialize context contracts (let ([f ( lambda () (x))]) for managing authority environments and enforcing access ( parameterize ([x 42]) control policies expressed in the logic (§3.3). (f)))) Fluid scoping is a useful programming construct because ( define-monitor users