Dynamic Security Labels and Static Information Flow Control Lantian Zheng Andrew C. Myers Computer Science Department Cornell University, Ithaca, NY 14853 fzlt,[email protected] Abstract be shown to enforce noninterference [13], a strong, end- to-end security property. For example, when applied to This paper presents a language in which information confidentiality, noninterference ensures that confidential flow is securely controlled by a type system, yet the se- information cannot be leaked by the program no matter curity class of data can vary dynamically. Information how it is transformed. flow policies provide the means to express strong secu- However, security cannot be enforced purely stat- rity requirements for data confidentiality and integrity. ically. In general, programs interact with an external Recent work on security-typed programming languages environment that cannot be predicted at compile time, has shown that information flow can be analyzed stat- so there must be a run-time mechanism that allows ically, ensuring that programs will respect the restric- security-critical decisions to be taken based on dynamic tions placed on data. However, real computing systems observations of this environment. For example, it is im- have security policies that cannot be determined at the portant to be able to change security settings on files time of program analysis. For example, a file has as- and database records, and these changes should affect sociated access permissions that cannot be known with how the information from these sources can be used. A certainty until it is opened. Although one security-typed purely static mechanism cannot enforce this. programming language has included support for dy- To securely control information flow when access namic security labels, there has been no demonstration rights can be changed and determined dynamically, dy- that a general mechanism for dynamic labels can se- namic labels [22] are needed that can be manipulated curely control information flow. In this paper, we present and checked at run time. Dynamic information control an expressive language-based mechanism for reasoning mechanisms [33, 6, 11, 17, 29, 10] support dynamic la- about dynamic security labels. The mechanism is for- bels and use run-time label tests to control information mally presented in a core language based on the typed flows. However, these dynamic mechanisms incur large lambda calculus; any well-typed program in this lan- run-time overhead and generally cannot prevent implicit guage is secure because it satisfies noninterference. flows arising from the control flow paths not taken at run time [7, 19]. Thus, it is desirable to combine dy- namic labels and static information flow control: making dynamic labels and run-time label tests explicit in pro- 1. Introduction grams and using static program analysis to reason about Information flow control protects information security their security properties. by constraining how information is transmitted among JFlow [21] and its successor, Jif [24] are the only objects and users of various security classes. These se- implemented security-typed languages supporting dy- curity classes are expressed as labels associated with the namic labels. However, although the Jif type system is information or its containers. Denning [8] showed how designed to control the new information channels that to use static analysis to ensure that programs use infor- dynamic labels create, it has not been proved to en- mation in accordance with its security class, and this ap- force secure information flow. Further, the dynamic la- proach has been instantiated in a number of languages in bel mechanism in Jif has limitations that impair expres- which the type system implements a similar static analy- siveness and efficiency. sis (e.g., [32, 15, 37, 26, 4, 28]). These type systems are In this paper, we propose an expressive language- an attractive way to enforce security because they can based mechanism for securely manipulating information with dynamic security labels. The mechanism is for- 2.1. Security classes malized in a core language λ (based on the typed DSec We assume that security requirements for confidentiality lambda calculus) with first-class label values, dependent or integrity are defined by associating security classes security types and run-time label tests. We prove the cor- with users and with the resources that programs access. rectness of this mechanism by showing that any well- These security classes form a lattice L. We write k v k0 typed program of the core language satisfies noninter- to indicate that security class k0 is at least as restric- ference, which intuitively means that confidential inputs tive as another security class k. In this case it is safe to cannot interfere with outputs observable to attackers. In move information from security class k to k0, because this paper, attackers are assumed to be passive in the restrictions on the use of the data are preserved. To con- sense that they can compromise data confidentiality only trol data derived from sources with classes k and k0, the by observing program outputs. With this passive attack least restrictive security class that is at least as restric- model, if a program satisfies noninterference, then at- tive as both k and k0 is assigned. This is the least upper tackers can learn nothing about confidential inputs of the bound, or join, written k t k0. program. This simple form of noninterference is stan- dard for security-typed languages, although dynamic la- bels introduce a subtle complexity: whether an input is 2.2. Labels confidential may not be statically determinable. Type systems for confidentiality or integrity are con- Some previous MAC systems have supported dy- cerned with tracking information flows in programs. namic security classes as part of a downgrading mecha- Types are extended with security labels that denote se- nism [30]. While downgrading is important, it is useful curity classes. A label ` appearing in a program may to treat it as a separate mechanism so that dynamic ma- be simply a constant security class k, or a more com- nipulation of labels does not necessarily destroy nonin- plex expression that denotes a security class. The no- terference. tation `1 v `2 means that `2 denotes a security class that is at least as restrictive as that denoted by ` . Intu- This paper is a revised and expanded version of a pa- 1 itively, data with label ` can be safely labeled with ` per presented at the second international Workshop on 1 2 if ` v ` holds. Thus, v is called the relabeling rela- Formal Aspects in Security and Trust [39]. Compared 1 2 tion. to that conference version, this paper includes a com- Because a given security class may be denoted by dif- plete proof that the λ type system enforces nonin- DSec ferent labels, the relation v generates a lattice of equiv- terference. Another improvement is that we demonstrate alence classes of labels with t as the join (least upper the dynamic label mechanisms of λ can be applied DSec bound) operator. Two labels ` and ` are equivalent, in practice by proposing a corresponding extension to 1 2 written ` ≈ ` , if ` v ` and ` v ` . The join of two Jif. 1 2 1 2 2 1 labels, `1 t `2, denotes the security class that is the join The remainder of this paper is organized as follows. of the security classes that `1 and `2 denote. For exam- Section 2 presents some background on lattice label ple, if variable x has label `x and variable y has label `y, models and security type systems. Section 3 introduces then the sum x+y is given the label `x t `y. the core language λDSec and uses sample λDSec pro- grams to show some important applications of dynamic 2.3. Security type systems for information labels. Section 4 describes the type system of λDSec. flow Section 5 proves that the λDSec type system enforces noninterference. Section 6 interprets and extends the dy- Security type systems can be used to enforce security namic label mechanism of Jif based on the ideas of information flows statically. Information flows in pro- λDSec. Section 7 covers related work, and Section 8 con- grams may be explicit flows such as assignments, or im- cludes. plicit flows arising from the control flow of the program. Consider an assignment statement x:=y, which contains an information flow from y to x. Then the typing rule for the assignment statement requires that `y v `x, which 2. Background means the security class of y is lower than the security class of x, guaranteeing the information flow from y to x Static information flow analysis can be formalized as a is secure. Intuitively, data with label `1 can be safely la- security type system, in which security labels of data beled with `2 if `1 v `2 holds. Thus, v is called the re- are represented by security type annotations, and infor- labeling relation. mation flow control is performed through type check- One advantage of static analysis is the ability to con- ing. trol implicit flows in all possible execution paths. Con- sider a simple conditional: • L 6v H, • the label of e is less than or equal to L, if s <= 0 then x := 0 else y := 0 and Although there is no direct assignment from s to x or y, • A1 ≈H A2, which means that for any this expression may cause implicit flows from s into x free variable x of e, if the label of x and y, since the values of x and y depend on s after eval- is not higher than or equal to H, then uating the expression. A standard technique for control- A1(x) = A2(x), ling implicit flows is to introduce a program-counter la- if e[A1] and e[A2] are evaluated to v1 and v2, bel [7], written pc, which indicates the security class of then v1 = v2.