Dynamic Security Labels and Noninterference

Lantian Zheng Andrew C. Myers Computer Science Department Cornell University, Ithaca, NY 14853 {zlt,andru}@cs.cornell.edu

Abstract matter how it is transformed. However, security cannot be enforced purely statically. This paper presents a language in which information flow is In general, programs interact with an external environment securely controlled by a type system, yet the security class that cannot be predicted at compile time, so there must be of data can vary dynamically. Information flow policies pro- a run-time mechanism that allows security-critical decisions vide the means to express strong security requirements for to be taken based on dynamic observations of this environ- data confidentiality and integrity. Recent work on security- ment. For example, it is important to be able to change secu- typed programming languages has shown that information rity settings on files and database records, and these changes flow can be analyzed statically, ensuring that programs will should affect how the information from these sources can be respect the restrictions placed on data. However, real com- used. A purely static mechanism cannot enforce this. puting systems have security policies that vary dynamically To securely control information flow when access rights and that cannot be determined at the time of program anal- can be changed and determined dynamically, dynamic la- ysis. For example, a file has associated access permissions bels [15] are needed that can be manipulated and checked at that cannot be known with certainty until it is opened. Al- run time. However, manipulating labels dynamically makes though one security-typed programming language has in- it more difficult to enforce a strong notion of information cluded support for dynamic security labels, there has been security for several reasons. First, changing the label of an no demonstration that a general mechanism for dynamic la- object may convert sensitive data to public data, directly vio- bels can securely control information flow. In this paper, we lating noninterference. Second, label changes (and changes present an expressive language-based mechanism for rea- to access rights in general) can be used to convey informa- soning about dynamic security labels. The mechanism is tion covertly; some restriction has to be imposed to prevent formally presented in a core language based on the typed covert channels [27, 22]. Some mandatory access control lambda calculus; any well-typed program in this language is (MAC) mechanisms support dynamic labels but cannot pre- provably secure because it satisfies noninterference. vent implicit flows arising from control flow paths not taken at run time [5, 12]. 1 Introduction JFlow [14] and its successor, Jif [17] are the only imple- mented security-typed languages supporting dynamic labels. Information flow control protects information security by However, although the Jif type system is designed to control constraining how information is transmitted among objects the new information channels that dynamic labels create, it and users of various security classes. These security classes has not been proved to enforce secure information flow. Fur- are expressed as labels associated with the information or its ther, the dynamic label mechanism in Jif has limitations that containers. Denning [6] showed how to use static analysis impair expressiveness and efficiency. to ensure that programs use information in accordance with In this paper, we propose an expressive language-based its security class, and this approach has been instantiated in mechanism for securely manipulating information with dy- a number of languages in which the type system implements namic security labels. The mechanism is formalized in a a similar static analysis (e.g., [25, 10, 30, 19, 3, 21]). These core language (based on the typed lambda calculus) with type systems are an attractive way to enforce security be- first-class label values, dependent security types and run- cause they can be shown to enforce noninterference [9], a time label tests. Further, we prove that any well-typed pro- strong, end-to-end security property. For example, when ap- gram of the core language is secure because it satisfies non- plied to confidentiality, noninterference ensures that confi- interference. This is the first noninterference proof for a dential information cannot be released by the program no security-typed language in which general security labels can be manipulated and tested dynamically, though a noninter- the security class that is the join of the security classes that ference result has been obtained for a simpler language sup- `1 and `2 denote. For example, if x has label `x and y has porting the related notion of dynamic principals [24]. label `y, then the sum x+y is given the label `x t `y. Some previous MAC systems have supported dynamic security classes as part of a downgrading mechanism [23]; 2.3 Security type systems for information flow in this work the two mechanisms are considered orthogonal. While downgrading is important, it is useful to treat it as a Security type systems can be used to enforce security infor- separate mechanism so that dynamic manipulation of labels mation flows statically. Information flows in programs may does not necessarily destroy noninterference. be explicit flows such as assignments, or implicit flows [6] The remainder of this paper is organized as follows. Sec- arising from the control flow of the program. Consider an tion 2 presents some background on lattice label models assignment statement x=y, which contains an information and security type systems. Section 3 introduces the core flow from y to x. Then the typing rule for the assignment ` v ` language λDSec and uses sample λDSec programs to show statement requires that y x, which means the security some important applications of dynamic labels. Section 4 level of y is lower than the security level of x, guaranteeing describes the type system of λDSec and proves the noninter- the information flow from y to x is secure. ference result. Section 5 covers related work, and Section 6 One advantage of static analysis is more precise control concludes. of implicit flows. Consider a simple conditional: if b then x = true else x = false 2 Background Although there is no direct assignment from b to x, this Static information flow analysis can be formalized as a se- expression has an implicit flow from b into x. A stan- curity type system, in which security levels of data are rep- dard technique for controlling implicit flows is to introduce resented by security type annotations, and information flow a program-counter label [5], written pc, which indicates control is performed through type checking. the security level of the information that can be learned by knowing the control flow path taken thus far. In this exam- 2.1 Security classes ple, the branch taken depends on b, so the pc in the then and else clauses will be joined with ` , the label of b. The type We assume that security requirements for confidentiality or b system ensures that any effect of expression e has a label at integrity are defined by associating security classes with least as restrictive as its pc. In other words, an expression e users and with the resources that programs access. These cannot generate any effects observable to users who should security classes form a lattice L. We write k v k0 to indi- not know the current program counter. In this example, the cate that security class k0 is at least as restrictive as another assignments to x will be permitted only if pc v ` , which security class k. In this case it is safe to move information x ensures ` v ` . from security class k to k0, because restrictions on the use of b x the data are preserved. To control data derived from sources with classes k and k0, the least restrictive security class that 3 The λDSec language is at least as restrictive as both k and k0 is assigned. This is the least upper bound, or join, written k t k0. The core language λDSec is a security-typed lambda calculus that supports first-class dynamic labels. In λDSec, labels are terms that can be manipulated and checked at run time. 2.2 Labels Furthermore, label terms can be used as statically analyzed Type systems for confidentiality or integrity are concerned type annotations. Syntactic restrictions are imposed on label with tracking information flows in programs. Types are ex- terms to increase the practicality of type checking, following Π tended with security labels that denote security classes. A the approach used by Xi and Pfenning in ML0 (C) [29]. label ` appearing in a program may be simply a constant se- From the computational standpoint, λDSec is fairly ex- curity class k, or a more complex expression that denotes a pressive, because it supports both first-class functions and security class. The notation `1 v `2 means that `2 denotes a state (which together are sufficient to encode recursive func- security class that is at least as restrictive as that denoted by tions). `1. Because a given security class may be denoted by differ- 3.1 Syntax ent labels, the relation v generates a lattice of equivalence classes of labels with t as the join (least upper bound) oper- The syntax of λDSec is given in Figure 1. We use the name k to range over a lattice of label values L (more precisely, a ator. Two labels `1 and `2 are equivalent, written `1 ≈ `2, if join semi-lattice with bottom element ⊥), x, y to range over `1 v `2 and `2 v `1. The join of two labels, `1 t `2, denotes

2 Base Labels k ∈ L Variables x, y, f ∈ V Locations m ∈ M Labels `, pc ::= k | x | `1 t `2 Constraints C ::= `1 v `2 ,C | C ; pc Base Types β ::= int | label | unit | (x:τ1)[C] ∗ τ2 | τ ref | (x:τ1) −−−→ τ2 Security Types τ ::= β` τ Values v ::= x | n | m | λ(x:τ)[C ; pc]. e | () | k | (x=v1[C], v2 :τ) τ Expressions e ::= v | `1 t `2 | e1 e2 | !e | e1 := e2 | ref e | if `1 v `2 then e1 else e2 | let (x, y)=e1 in e2

Figure 1: Syntax of λDSec variable names V, and m to range over a space of memory function types. The empty constraint set C or the top pc can addresses M. be omitted. A pair (x=v1[C], v2 :τ) contains two values v1 To make the lattice explicit, we write L |= k1 v k2 and v2. The second element v2 has type τ and may mention to mean that k2 is at least as restrictive as k1 in L, and the first element v1 by the name x. The component C is a set L |= k = k1 t k2 to mean k is the join of k1 and k2 in of label constraints that the first element of the pair must sat- L. The least and greatest elements of L are ⊥ and >. Any isfy. For example, suppose C contains the constraint x v L, non-trivial label lattice contains at least two points L and H then v1 v L must be true since inside the pair the value of x where H 6v L. Intuitively, the label L describes what in- is v1. formation is observable by low-security users who are to be Expressions include values v, variables x, the join of two prevented from seeing confidential information. Thus, low- labels `1 t `2, applications e1 e2, dereferences !e, assign- τ security data has a label bounded above by L; high-security ments e1 := e2, references ref e, label-test expressions data has a label (such as H) not bounded by L. if `1 v `2 then e1 else e2, and product destructors In λDSec, a label can be either a label value k, a variable let (x, y)=v in e2. x, or the join of two other labels `1 t `2. For example, L, x, The label-test expression if `1 v `2 then e1 else e2 and L t x are all valid labels, and L t x can be interpreted is used to examine labels. At run time, if the value of `2 is as a security policy that is as restrictive as both L and x. The a constant label at least as restrictive as the value of `1, then security type τ = β` is the base type β annotated with label e1 is evaluated; otherwise, e2 is evaluated. Consequently, `. The base types include integers, unit, labels, functions, the constraint `1 v `2 can be assumed when type-checking references and products. e1. C ; pc The product destructor let (x, y)=e in e unpacks the The function type (x : τ1) −−−→ τ2 is a dependent type 1 2 result of e , which is a pair, assigns the first element to x and since τ1, τ2, C and pc may mention x. The component C is 1 the second to y, and then evaluates e . a set of label constraints each with the form `1 v `2; they 2 must be satisfied when the function is invoked. The pc component is a lower bound on the memory effects of the func- 3.2 Operational Semantics tion, and an upper bound on the pc label of the caller. Con- The small-step operational semantics of λ is given in sequently, a function is not able to leak information about DSec Figure 2. Let M represent a memory that is a finite map where it is called. Without the annotations C and pc, this from typed locations to closed values, and let he, Mi be kind of type is sometimes written as Πx:τ .τ [13]. 1 2 a machine configuration. Then a small evaluation step is The product type (x : τ )[C] ∗ τ is also a dependent 1 2 a transition from he, Mi to another configuration he0,M 0i, type in the sense that occurrences of x can appear in τ , τ 1 2 written he, Mi 7−→ he0,M 0i. and C. The component C is a set of label constraints that It is necessary to restrict the form of he, Mi to avoid us- any value of the product type must satisfy. If τ does not 2 ing undefined memory locations. Let loc(e) represent the set contain x and C is empty, the type may be written as the of memory locations appearing in e. A memory M is well- more familiar τ ∗ τ . Without the annotation C, this kind of 1 2 formed if every address m appears at most once in dom(M), type is sometimes written Σx:τ .τ [13]. 1 2 and for any mτ in dom(M), loc(M(mτ )) ⊆ dom(M). The In λ , values include integers n, typed memory lo- DSec configuration he, Mi is well-formed if M is well-formed, cations mτ , functions λ(x : τ)[C ; pc]. e, the unit value (), loc(e) ⊆ dom(M), and e contains no free variables. By in- constant labels k, and pairs (x = v [C], v : τ). A function 1 2 duction on the derivation of he, Mi 7−→ he0,M 0i, we can λ(x : τ)[C ; pc]. e has one argument x with type τ, and the prove that if he, Mi is well-formed, then he0,M 0i is also components C and pc have the same meanings as those in well-formed.

3 L |= k = k1 t k2 [E1] hk1 t k2,Mi 7−→ hk, Mi

[E2] h!mτ ,Mi 7−→ hM(mτ ),Mi

m 6∈ address-space(M) [E3] hrefτ v, Mi 7−→ hmτ ,M[mτ 7→ v]i

[E4] hmτ := v, Mi 7−→ h(),M[mτ 7→ v]i

[E5] h(λ(x:τ)[C ; pc]. e) v, Mi 7−→ he[v/x],Mi

L |= k1 v k2 [E6] hif k1 v k2 then e1 else e2,Mi 7−→ he1,Mi

L |= k1 6v k2 [E7] hif k1 v k2 then e1 else e2,Mi 7−→ he2,Mi

[E8] hlet (x, y)=(x=v1[C], v2 :τ) in e, Mi 7−→ he[v2/y][v1/x],Mi

he, Mi 7−→ he0,M 0i [E9] hE[e],Mi 7−→ hE[e0],M 0i

τ E[·] ::= [·] e | v [·] | [·] := e | v := [·] | ![·] | ref [·] | [·] t `2 | k1 t [·] | if [·] v `2 then e1 else e2 | if k1 v [·] then e1 else e2 | let (x, y)=[·] in e

Figure 2: Small-step operational semantics of λDSec

The notation e[v/x] indicates capture-avoiding substitu- programs and the external environment. A practical pro- tion of value v for variable x in expression e. Unlike in the gram often needs to access files or communicate through typed lambda calculus, e[v/x] may generate a syntactically networks. These activities can be viewed as communication ill-formed expression if x appears in type annotations inside through an I/O channel with a corresponding label consis- e, and v is not a label. However, this is not a problem be- tent with the security policy of the entity (such as a file or cause the type system of λDSec guarantees that a well-typed network socket) represented by the channel. Because the expression can only be evaluated to another well-typed and security policy of an external entity may be discovered and thus well-formed expression. even changed at run time, the precise label of an I/O channel The notation M(mτ ) denotes the value of location mτ is dynamic and operations on a channel cannot be checked in M, and the notation M[mτ 7→ v] denotes the memory at compile time. obtained by assigning v to mτ in M. The evaluation rules are standard. In rule (E3), the nota- 3.3.1 Run-time access control tion address-space(M) represents the set of location names τ in M, that is, {m | ∃τ s.t. m ∈ dom(M)}. In rule (E8), v2 Implementing run-time access control is one of the most may mention x, so substituting v2 for y in e is performed be- important applications of dynamic label mechanisms. Sup- fore substituting v1 for x. The variable name in the product pose there exists a file that stores one integer, and the ac- value matches x so that no variable substitution is needed cess control policy of the file is unknown at compile time. λ when assigning v1 and v2 to x and y. In rule (E9), E rep- In DSec, the file can be encoded as a reference of type resents an evaluation context, a term with a single hole in (x : label⊥) ∗ (intx ref)⊥, where x is a dynamic label redex position, and the syntax of E specifies the evaluation consistent with the access control policy of the file, and the order. reference component of type (intx ref)⊥ stores the contents of the file. Thus storing an integer of type intH in the file is equivalent to assigning the integer to the memory ref- 3.3 Examples erence component, which requires that x is at least as high As discussed in Section 1, dynamic labels are vital for pre- as H. Since the value of x is not known at compile time, cisely controlling information flows between security-typed the condition H v x can only be checked at run time, us-

4 ing a label-test expression. The following function stores a ((x : labelx)[x v `] ∗ intx)⊥ ref, where ` is the label high-security integer z in the file w: of the channel, and the constraint x v ` guarantees any information stored in the reference has a security label at most λw :((x:label⊥) ∗ (intx ref)⊥)⊥ ref⊥. λ(z :intH )[H]. as high as `. Sending information through a bounded multi- let (x, y)=!w in if H v x then y := z else () level channel often needs a run-time check as in the following code: Note that the pc label of the function is H because the function body contains a memory effect of label x when H v x. λz :(((x:labelx))[x v `] ∗ intx)⊥ ref)⊥. λw :labelw. It is also important to be able to change file permissions λ(y :intw)[⊥]. if w v ` then z := (x=w, y :intx) else () at run time. The following code changes the access control policy of the file w to label z. However, the original con- The ability to recursively use a variable to construct the tents of w need to be wiped out to prevent them from being label of its own type provides a useful kind of polymor- implicitly declassified, which provides stronger security as- phism, which this example demonstrates. Without recursive surance than an ordinary file system. labels, the type of a multilevel channel cannot be constructed so simply, because selecting a label for the label component λw :((x: ) ∗ ) . λ(z : )[⊥]. label⊥ intx ref⊥ ⊥ ref⊥ label⊥ x becomes problematic. Any constant label that is chosen (λ(y :int ref )[⊥]. w := (x=z, y :int ref ))refintz 0 z ⊥ x ⊥ may be inappropriate; for example, if the label has the label ⊥ then it may be impossible to compute a suitable label to supply as x. Another possibility is to provide yet another la- 3.3.2 Multilevel communication channels bel that is to function as the label of x, but this merely pushes Information flows inside a program are controlled by static the problem back by one level. Giving x the type labelx is type checking. When information is exported outside a pro- a neat way to tie off this sequence. gram through an I/O channel, the receiver might want to know the exact label of the information, which calls for mul- 4 Type system and noninterference tilevel communication channels [7] unambiguously pairing the information sent or received with its corresponding se- This section describes the type system of λDSec and proves curity label. Supporting multilevel channels is one of the that the type system guarantees that any well-typed program basic requirements for a MAC system [7]. has the noninterference property. In λDSec, a multilevel channel can be encoded by a memory reference of type ((x : labelx) ∗ intx)⊥ ref, which 4.1 Label constraints stores a pair composed of an integer value and its label. Because of dynamic labels, it is not always possible to de- The confidentiality of the integer component is protected by cide whether the relationship ` v ` holds at compile the label component, since extracting the integer component 1 2 time; therefore, the label-test expression (if) must be used from such a pair requires testing the label component: to query the relationship. However, this dynamic query may

λz :((x:labelx) ∗ intx)⊥. let (x, y)=z in create new information flows; the language λDSec and its if x v L then mintL := y else () type system are designed to statically control these new information flows. x v L In the above example, the constraint must be satisfied Although labels are first-class values in λDSec, label int in order to store the integer component in m L . Since the terms have a restricted syntactic form so that any label term readability of the integer component depends on the value of can be used as a type annotation. Therefore, constraints on x, letting x recursively label itself ensures that all the autho- label terms are also type-level information that can be used rized readers of the integer component can test x and retrieve by the type checker. the integer value. Furthermore, in λDSec label terms are purely functional: Sending an integer through a multilevel channel is im- they have no side effects and evaluate to the same value in plemented by pairing the integer and its label and storing the the same context. As a result, any label constraint of the pair in the reference representing the channel: form `1 v `2 that is known to hold in a typing context can be used for type checking in that context. For example, consider λz :(((x:label )) ∗ int ) ref) . λw :label . x x ⊥ ⊥ w the following code: λ(y :intw)[⊥]. z := (x=w, y :intx) λx:label⊥. λy :(intx ref)⊥. λ(z :intH )[H]. Like other I/O channels, a multilevel channel may have a if H v x then y := z else () label that is an upper bound of the security levels of the information that can be sent through the channel. Product According to the semantics of the label-test expression, the label constraints can be used to specify the label of a mul- assignment y := z will be executed only if H v x holds. tilevel channel. For example, a bounded multilevel chan- Thus, the constraint H v x can be used to decide whether nel can be represented by a memory reference with type z := y is secure. In this example, any information stored

5 L |= k1 v k2 `1 v `2 ∈ C ` ` v ` [C1] [C2] may be treated as data with label 2, which requires 1 2. C ` k1 v k2 C ` `1 v `2 The type system keeps track of the set of label constraints that can be used to prove relabeling relationships between [C3] C ` ` v > [C4] C ` ⊥ v ` labels. Let C ` `1 v `2 denote that `1 v `2 can be in- ferred from the set of constraints C. The inference rules are [C5] C ` ` v ` t `0 shown in Figure 3; they are standard and consistent with the lattice properties of labels. Rule (C2) shows that all the con- C ` `1 v `2 C ` `2 v `3 [C6] straints in C are assumed to be true. The constraint set C C ` `1 v `3 may contain constraints that are inconsistent with the lattice C ` `1 v `3 C ` `2 v `3 L, such as H v L. Inconsistent constraint sets are harmless [C7] C ` `1 t `2 v `3 because they always indicate dead code, such as expression e1 in “if H v L then e1 else e2”. Since the subtyping relationship depends on the rela- Figure 3: Relabeling rules beling relationship, the subtyping context also needs to include the C component. The inference rules for proving C ` τ1 ≤ τ2 C ` τ2 ≤ τ1 C ` τ ≤ τ are the rules shown in Figure 4 plus the stan- [S1] 1 2 C ` τ1 ref ≤ τ2 ref dard reﬂexivity and transitivity rules. Rules (S1)–(S3) are about subtyping on base types. 0 0 C ` τ2 ≤ τ1 C ` τ1 ≤ τ2 These rules demonstrate the expected covariance or con- C ` pc v pc C,C2 ` C1 2 1 travariance. In λDSec, function types contain two additional [S2] C1 ; pc1 0 C2 ; pc2 0 components pc and C, both of which are contravariant. Sup- C ` (x:τ1) −−−−→ τ1 ≤ (x:τ2) −−−−→ τ2 C1 ; pc1 0 pose the function type τ = (x : τ1) −−−−→ τ is a sub- 0 0 1 C ` τ1 ≤ τ2 C ` τ1 ≤ τ2 C,C1 ` C2 C2 ; pc [S3] type of τ 0 = (x : τ ) −−−−→2 τ 0 . Then wherever functions C ` (x:τ )[C ] ∗ τ 0 ≤ (x:τ )[C ] ∗ τ 0 2 2 1 1 1 2 2 2 with type τ 0 can be called, functions with type τ can also

C ` β1 ≤ β2 C ` `1 v `2 be called. This implies two necessary premises. First, wher- [S4] ever C2 is satisfied, C1 is also satisfied. Since C is satisfied, C ` (β1)`1 ≤ (β2)`2 this premise is written C,C2 ` C1, meaning that for any constraint `1 v `2 in C1, we can derive C,C2 ` `1 v `2. Figure 4: Subtyping rules Second, the premise pc2 v pc1 is needed because the pc of a function type is an upper bound on the pc where the function in z is only accessible to users with security level at least as is applied. high as x. So it is secure to store z in y because x is at least In rules (S2) and (S3), variable x is bound in the function as high as H. and product types. For simplicity, we assume that x does In general, for each expression e, the type checker keeps not appear in C, since α-conversion can always be used to track of the set of constraints C that are known to be satisfied rename x to another fresh variable. This assumption also when e is executed, and uses C in type-checking e. applies to the typing rules. Another common approach for relating type information Rule (S4) is used to determine the subtyping on security to term-level constructs is to use singleton types, types con- types. The premise C ` β1 ≤ β2 is natural. The other taining only one value [2]. We have chosen to use dependent premise C ` `1 v `2 guarantees that coercing data from τ1 types because it is the approach used by Jif, and the approach to τ2 does not violate information flow policies. based on singleton types neither provides more expressiveness nor simplifies the type system or the noninterference 4.3 Typing proof in any substantial way. In general, we feel that the The type system of λ prevents illegal information flows choice between dependent types and singletons is a matter DSec and guarantees that well-typed programs have a noninterfer- of taste. ence property. The typing rules are shown in Figure 5. The notation label(β`) = ` is used to obtain the label of a type, 4.2 Subtyping and the notations ` v τ and τ v ` are abbreviations for The subtyping relationship between security types plays an ` v label(τ) and label(τ) v `, respectively. important role in enforcing information flow security. Given The typing context includes a type assignment Γ, a set of constraints C and the program-counter label pc. Γ is a finite two security types τ1 = β1` and τ2 = β2` , suppose τ1 is 1 2 ordered list of x : τ pairs in the order that they came into a subtype of τ2, written as τ1 ≤ τ2. Then any data of type scope. For a given x, there is at most one pair x:τ in Γ. τ1 can be treated as data of type τ2. Thus, data with label `1

6 [INT]Γ; C ; pc ` n : int⊥ [UNIT]Γ; C ; pc ` () : unit⊥

FV (τ) = ∅ [LOC] τ [LABEL]Γ; C ; pc ` k : label⊥ Γ; C ; pc ` m :(τ ref)⊥

Γ; C ; pc ` `1 : label 0 Γ; C ; pc ` `2 : label 0 `1 `2 x:τ ∈ Γ [JOIN] [VAR] Γ; C ; pc ` `1 t `2 : label 0 0 Γ; C ; pc ` x : τ `1t`2

Γ; C ; pc ` e : τ C ` pc v τ Γ; C ; pc ` e :(τ ref)` [REF] τ [DEREF] Γ; C ; pc ` ref e :(τ ref)⊥ Γ; C ; pc `!e : τ t `

Γ; C ; pc ` e1 :(τ ref)` Γ, x:τ 0 ; C0 ; pc0 ` e : τ Γ; C ; pc ` e2 : τ C ` pc t ` v τ 0 0 [ABS] 0 0 0 0 C ; pc [ASSIGN] Γ; C ; pc ` λ(x:τ )[C ; pc ]. e : ((x:τ ) −−−−→ τ)⊥ Γ; C ; pc ` e1 := e2 : unit⊥

0 0 0 0 C ; pc 0 C ; pc Γ; C ; pc ` e1 : ((x:label`0 ) −−−−→ τ)` Γ; C ; pc ` e1 : ((x:τ ) −−−−→ τ)` 0 0 Γ; C ; pc ` `2 : label` [`2/x] Γ; C ; pc ` e2 : τ 0 0 0 0 C ` pc t ` v pc [`2/x] C ` C [`2/x] C ` pc t ` v pc C ` C x ∈ FV (τ) ∪ FV (`0) ∪ FV (C0) ∪ FV (pc0) x∈ / FV (τ) ∪ FV (τ 0) ∪ FV (C0) ∪ FV (pc0) [L-APP] [APP] Γ; C ; pc ` e1 `2 : τ[`2/x] t ` Γ; C ; pc ` e1 e2 : τ t `

0 Γ; C ; pc ` v1 : τ1[v1/x]Γ, x:τ1 ` τ2 Γ; C ; pc ` e1 : ((x:τ1)[C ] ∗ τ2)` 0 0 Γ; C ; pc ` v2[v1/x]: τ2[v1/x] C ` C [v1/x] Γ, x:τ1 t`, y :τ2 t` ; C,C ; pc ` e2 : τ [PROD] 0 0 [UNPACK] Γ; C ; pc ` (x=v1[C ], v2 :τ2) : ((x:τ1)[C ] ∗ τ2)⊥ Γ; C ; pc ` let (x, y)=e1 in e2 : τ

Γ; C ; pc ` `i : label 0 i ∈ {1, 2} `i 0 0 Γ; C, `1 v `2 ; pc t `1 t `2 ` e1 : τ 0 0 0 Γ; C ; pc t `1 t `2 ` e2 : τ Γ; C ; pc ` e : τ C ` τ ≤ τ [IF] 0 0 [SUB] 0 Γ; C ; pc ` if `1 v `2 then e1 else e2 : τ t `1 t `2 Γ; C ; pc ` e : τ

Figure 5: Typing rules for the λDSec language

A variable appearing in a type must be a label variable. check values. Value v has type β⊥ if v has base type β. Rule Therefore, a type τ is well-formed with respect to type as- (LOC) requires typed location mτ contain no label variables signment Γ, written Γ ` τ, if Γ maps all the variables in τ so that mτ remains a constant during evaluation. This is to label types. The definition of well-formed labels (Γ ` `) enforced by the premise FV (τ) = ∅, where FV (τ) denotes is the same. Consider Γ = x1 : τ1, . . . , xn : τn. For any the set of free variables appearing in τ. 0 ≤ i ≤ n, the type τi may only mention label variables that Rule (VAR) is standard: variable x has type Γ(x). Rule are already in scope: x1 through xi. Therefore, Γ is well- (JOIN) checks the join of two labels and assigns a result la- formed if for any 0 ≤ i ≤ n, τi is well-formed with respect bel that is the join of the labels of the operands. to x1 : τ1, . . . , xi : τi. For example, “x : labelL, y : intx” Rule (REF) checks memory allocation operations. If the is well-formed, but “y : intx, x : labelL” is not. A con- pc label is high, the generated memory location must not be straint `1 v `2 is well-formed with respect to Γ if both `1 observable to low-security users, which is guaranteed by the and `2 are well-formed with respect to Γ. A typing context premise C ` pc v τ. Rule (DEREF) checks dereference “Γ; C ; pc” is well-formed if Γ is well-formed, and pc and expressions. Since some information about a reference can all the constraints in C are well-formed with respect to Γ. be learned by knowing its contents, the result of dereferenc- The typing assertion Γ; C ; pc ` e : τ means that with ing a reference with type (τ ref)` has type τ t `, where the type assignment Γ, current program-counter label as pc, τ t ` = β`0t` if τ is β`0 . and the set of constraints C satisfied, expression e has type Rule (ASSIGN) checks memory update. As in rule τ. The assertion Γ; C ; pc ` e : τ is well-formed if Γ; C ; pc (REF), if the updated memory location has type (τ ref)`, is well-formed, and Γ ` τ. then C ` pc v τ is required to prevent illegal implicit flows. Rules (INT), (UNIT), (LABEL) and (LOC) are used to In addition, the premise C ` pc t ` v τ implies another

7 condition C ` ` v τ that is required to protect the confiden- Rule (IF) checks label-test expressions. The constraint tiality of the reference that is assigned to. Consider the fol- `1 v `2 is added into the typing context when checking the lowing code that allows low-security users to learn whether first branch e1. When checking the branches, the program- x v L by observing which of m1 and m2 is updated to 0: counter label subsumes the labels of `1 and `2 to protect 0 intL intL them from implicit flows. The resulting type contains `1 and λ(x:labelH )[L]. ((ifx v Lthen m1 else m2 ) := 0) 0 `2 because the result is influenced by the values of `1 and `2. The code is not well-typed because the condition C ` ` v τ Rule (SUB) is the standard subsumption rule. If τ is a does not hold for the assignment expression. subtype of τ 0 with the constraints in C satisfied, then any Rule (ABS) checks function values. The body is checked expression of type τ also has type τ 0. with the constraint set C0 and the program-counter label pc0, This type system satisfies the subject reduction property so the function can only be called at places where C0 is sat- and the progress property. The proof is standard, so we sim- isfied and the pc label is not more restrictive than pc0. ply state the theorems here. Rule (L-APP) is used to check applications of depen- Definition 4.1 (Well-typed memory). A memory M is dent functions. Expression e1 has a dependent function τ τ C0 ; pc0 well-typed if for any memory location m in M, ` M(m ): type ((x : label`0 ) −−−−→ τ)`, where x does appear in τ. `0, C0, pc0 or τ. As a result, rule (L-APP) needs to use 0 0 0 ` [`2/x], C [`2/x], pc [`2/x] and τ[`2/x], which are well- Theorem 4.1 (Subject reduction). Suppose pc ` e : τ, and formed since `2 is a label. That also explains why e1, with there exists a well-typed memory M such that he, Mi 7−→ its dependent function type, cannot be applied to an arbi- he0,M 0i, then M 0 is well-typed, and pc ` e0 : τ. trary expression e : substituting e for x in `0, C0, pc0 and 2 2 Theorem 4.2 (Progress). If pc ` e : τ, and M is a well- τ may generate ill-formed labels or types, and it is generally typed memory such that he, Mi is a well-formed configura- unacceptable for the type checker to evaluate e to value v 2 2 tion, then either e is a value or there exists e0 and M 0 such and substitute v for x, which would make type-checking 2 that he, Mi 7−→ he0,M 0i. undecidable. The expressiveness of λDSec is not substan- tially affected by the restriction that a dependent function can only be applied to label terms, because the function can 4.4 Noninterference proof be applied to a variable that receives the result of an arbi- This section outlines a proof that any well-typed program in trary expression. For example, in the following code, the λDSec satisfies the noninterference property. (The full proof e x e e application 1 indirectly applies 1 to 2: is given in the appendix.) Consider an expression e in λDSec. (λx:label`. if x v L then e1x else ())e2 Suppose e has one free variable x, and x : τ ` e : intL where H v τ. Thus, the value of x is a high-security input This works as long as the function enclosing e x is not de- 1 to e, and the result of e is a low-security output. Then nonin- pendent. terference requires that for all values v of type τ, evaluating In rule (L-APP), the label of e ` is at least as restric- 1 2 e[v/x] in the same memory must generate the same result, tive as `, preventing the result of e from being leaked. The 1 if the evaluation terminates. For simplicity, we only con- premise C ` C0[` /x] guarantees that C0[` /x] are satisfied 2 2 sider that results are integers because they can be compared when the function is invoked. The premise C ` pc t ` v outside the context of λ . pc0[` /x] ensures that the invocation cannot leak the pro- DSec 2 The noninterference property discussed here is termina- gram counter or the function itself through the memory ef- tion insensitive [21] because e[v/x] is required to generate fects of the function. the same result only if the evaluation terminates. The type Rule (APP) applies when x does not appear in C0, pc0 or system of λ does not attempt to control termination and τ. In this case, the type of e is just a normal function type, DSec 1 timing channels. Control of these channels is largely an or- so e can be applied to arbitrary terms. 1 thogonal problem. Termination channels can leak at most Rule (PROD) is used to check product values. To check one bit per run, so they have often been considered accept- v , the occurrences of x in v and τ are both replaced by 2 2 2 able (e.g., [6, 25]). Some recent work [1, 20, 31] partially v , since x is not in the domain of Γ. If v is not a label, 1 1 addresses the control of timing channels. then x cannot appear in τ . Thus, τ [v /x] is always well- 2 2 1 Let 7−→∗ denote the transitive closure of the 7−→ rela- formed no matter whether v1 is a label or not. Similarly, the 0 tionship. The following theorem formalizes the claim that occurrences of x in τ1 and C are also replaced by v1 when 0 the type system of λDSec enforces noninterference: v1 and C are checked. Rule (UNPACK) checks product destructors straightfor- Theorem 4.3 (Noninterference). Suppose x : τ ` e : wardly. After unpacking the product value, those product intL, and H v τ. Given two arbitrary values v1 and v2 0 ∗ label constraints in C are in scope and used for checking of type τ, and an initial memory M, if he[vi/x],Mi 7−→ 0 0 0 0 e2. hvi,Mi i for i ∈ {1, 2}, then v1 = v2.

8 To prove this noninterference theorem, we adapt the el- The appendix details the syntax and semantic extensions 2 egant proof technique developed by Pottier and Simonet for of λDSec and proves the key subject reduction theorem of 2 an ML-like security-typed language [19] (which did not have λDSec. The major extension to Pottier’s proof technique is dynamic labels). To show that noninterference holds, it that the bracket construct must also be applied to labels. Be- is necessary to reason about the executions of two related cause types may contain bracketed labels, the projection op- terms: e[v1/x] and e[v2/x]. We extend λDSec with a bracket eration also applies to typing environments. construct (e1 |e2) that represents alternative expressions that might arise during the evaluation of two programs that dif- 5 Related Work fers initially only in v1 and v2. Then e[v1/x] and e[v2/x] can be incorporated into a single term e[(v1 | v2)/x] in the Dynamic information flow control mechanisms [26, 27] 2 extended language λDSec, providing a syntactic way to rea- track security labels dynamically and use run-time security son about two executions. checks to constrain information propagation. These mecha- 2 Using λDSec, the noninterference theorem can be proved nisms are transparent to programs, but they cannot prevent in three steps: illegal implicit flows arising from the control flow paths not taken at run time. 1. Prove that the evaluation of λ2 adequately repre- DSec Various general security models [11, 23, 8] have been sents the execution of two λ terms. Given a λ2 DSec DSec proposed to incorporate dynamic labeling. Unlike noninter- term e, let bec and bec represent the two λ terms 1 2 DSec ference, these models define what it means for a system to encoded by e. Further, if M maps x to a λ2 term e, DSec be secure according to a certain relabeling policy, which may then bMc maps x to bec for i ∈ {1, 2}. Then we can i i allow downgrading labels. formalize the adequacy of λ2 as the following two DSec Using static program analysis to check information flow lemmas (their proof is straightforward): was first proposed by Denning and Denning [6]; later work Lemma 4.1 (Soundness). If he, Mi 7−→ he0,M 0i, phrased the analysis as type checking (e.g., [18]). Noninter- 0 0 then hbeci, bMcii 7−→ hbe ci, bM cii for i ∈ {1, 2}. ference was later developed as a more semantic characteriza- tion of security [9], followed by many extensions. Volpano, ∗ Lemma 4.2 (Completeness). If hbeci, bMcii 7−→ Smith and Irvine [25] first showed that type systems can be 0 hvi,Mi i for i ∈ {1, 2}, then there exists a configu- used to enforce noninterference, and proved a version of 0 ∗ 0 ration hv, M i such that he, Mi 7−→ hv, M i. noninterference theorem for a simple imperative language, starting a line of research pursuing the noninterference re- 2. Prove that λ2 satisfies subject reduction: the result DSec sult for more expressive security-typed languages. Heintze of an expression has the same type as the expression. and Riecke [10] proved the noninterference theorem for the The type system of λ2 explicitly enforces noninter- DSec SLam calculus, a purely functional language. Zdancewic ference by requiring that any bracket expression (e |e ) 1 2 and Myers [30] investigated a secure calculus with first-class has a high-security type. The differences between two continuations and references. Pottier and Simonet [19] con- executions are completely captured by bracket expres- sidered an ML-like functional language and introduced the sions, so the requirement that brackets must have high- proof technique that is extended in this paper. A more com- security types ensures that the differences between the plete survey of language-based information-flow techniques two executions are unobservable to low-security users. can be found in [21, 32]. Intuitively, it is because of the explicit enforcement The Jif language [14, 17] extends Java with a type sys- of noninterference that the noninterference theorem of tem for analyzing information flow, and aims to be a prac- λ can be reduced to the soundness (subject reduc- DSec tical language for developing secure applications. However, tion) of the type system of λ2 . DSec there is not yet a noninterference proof for the type system

3. Prove the noninterference theorem of λDSec: Be- of Jif, because of its complexity. This work is inspired by ∗ 0 0 the dynamic label mechanism of Jif, although the dynamic cause he[vi/x],Mi 7−→ hvi,Mi i and e[vi/x] = be[(v1 | v2)/x]ci for i ∈ {1, 2}, by the com- label mechanism in λDSec is more expressive. Jif provides pleteness lemma there exists hv0,M 0i such that two constructs for run-time label tests: the switch-label ∗ 0 0 0 he[(v1 | v2)/x],Mi 7−→ hv ,M i. Moreover, bv ci = statement and the actsFor statement, both of which can be 0 encoded using the label-test expression in λ . The typ- vi for i ∈ {1, 2} by the soundness lemma. To prove DSec the noninterference theorem, we only need to prove ing rules for switch-label and actsFor are as restrictive 0 0 0 0 as the typing rule of the label-test expression. Thus, the non- v1 = v2, that is, bv c1 = bv c2. By the subject re- 2 0 interference result for λ provides strong evidence that duction theorem of λDSec, ` v : intL. By the type DSec 2 0 these dynamic label constructs in Jif are secure. system of λDSec, v cannot be a bracket construct because it has a low-security type. Consequently, v0 must Banerjee and Naumann [4] proved a noninterference re- 0 0 be an integer n. Then we have bv c1 = n = bv c2. sult for a Java-like language with simple access control prim-

9 itives. Unlike in λDSec, run-time access control in this lan- References guage is separate from the static label mechanism because [1] Johan Agat. Transforming out timing leaks. In Proc. 27th ACM it is inspired by Java stack inspection. In their language, Symp. on Principles of Programming Languages (POPL), pages 40– the label of a method result may depend in limited ways on 53, Boston, MA, January 2000. the (implicit) security state of its caller; however, it does not [2] David Aspinall. Subtyping with singleton types. In Computer Science seem to be possible in the language to control the flow of in- Logic (CSL), Kazimierz, Poland, pages 1–15. Springer-Verlag, 1994. formation from an I/O channel or file based on permissions [3] Anindya Banerjee and David A. Naumann. Secure information flow discovered at run time. and pointer confinement in a Java-like language. In IEEE Computer Concurrent to our work, Tse and Zdancewic proved a Security Foundations Workshop (CSFW), June 2002. noninterference result for a security-typed lambda calculus [4] Anindya Banerjee and David A. Naumann. Using access control (λ ) with run-time principals [24], which can be used to for secure information flow in a java-like language. In Proc. 16th RP IEEE Computer Security Foundations Workshop, pages 155–169, construct dynamic labels. However, λRP does not support June 2003. references or existential types, which makes it unable to rep- [5] Dorothy E. Denning. Cryptography and Data Security. Addison- resent dynamic security policies that may be changed at run Wesley, Reading, Massachusetts, 1982. time, such as file permissions. As discussed in Section 1, [6] Dorothy E. Denning and Peter J. Denning. Certification of programs modeling real systems requires this ability. By comparison, for secure information flow. Comm. of the ACM, 20(7):504–513, July in λDSec the label stored in a reference may be updated at 1977. run time, and with dependent existential types, we can en- [7] Department of Defense. Department of Defense Trusted Computer sure that a piece of data and its label are updated consistently. System Evaluation Criteria, DOD 5200.28-STD (The Orange Book) edition, December 1985. Therefore, updating a label dynamically does not declassify confidential data. In addition, support for references makes [8] Simon Foley, Li Gong, and Xiaolei Qian. A security model of dynamic labeling providing a tiered approach to verification. In IEEE λDSec more powerful than λRP computationally. Symposium on Security and Privacy, pages 142–154, Oakland, CA, Other work [29, 28] has used dependent type systems to 1996. IEEE Computer Society Press. specify complex program invariants and to statically catch [9] Joseph A. Goguen and Jose Meseguer. Security policies and security program errors considered run-time errors by traditional type models. In Proc. IEEE Symposium on Security and Privacy, pages systems. This work also makes a trade-off between expres- 11–20, April 1982. sive power and practical type checking. [10] Nevin Heintze and Jon G. Riecke. The SLam calculus: Programming with secrecy and integrity. In Proc. 25th ACM Symp. on Principles of Programming Languages (POPL), pages 365–377, San Diego, Cali- 6 Conclusions fornia, January 1998. [11] John McLean. The algebra of security. In IEEE Symposium on Secu- This paper formalizes computation and static checking of rity and Privacy, pages 2–7, Oakland, California, 1988. dynamic labels in the type system of a core language λDSec [12] Catherine Meadows. Policies for dynamic upgrading. In Database and proves a noninterference result: well-typed programs Security, IV: Status and Prospects, pages 241–250. North Holland, 1991. have the noninterference property. The language λDSec is the first language supporting general dynamic labels whose [13] John C. Mitchell. Foundations for Programming Languages. The type system provably enforces noninterference. MIT Press, Cambridge, Massachusetts, 1996. [14] Andrew C. Myers. JFlow: Practical mostly-static information flow control. In Proc. 26th ACM Symp. on Principles of Programming Acknowledgements Languages (POPL), pages 228–241, San Antonio, TX, January 1999. [15] Andrew C. Myers and Barbara Liskov. A decentralized model for The authors would like to thank Greg Morrisett, Steve information flow control. In Proc. 17th ACM Symp. on Operating Zdancewic and Amal Ahmed for their insightful sugges- System Principles (SOSP), pages 129–142, Saint-Malo, France, 1997. tions. Steve Chong, Nate Nystrom, and Michael Clarkson [16] Andrew C. Myers and Barbara Liskov. Protecting privacy using the also helped improve the presentation of this work. decentralized label model. ACM Transactions on Software Engineer- This work was supported by the Department of the Navy, ing and Methodology, 9(4):410–442, October 2000. Office of Naval Research, under ONR Grant N00014-01-1- [17] Andrew C. Myers, Lantian Zheng, Steve Zdancewic, Stephen Chong, and Nathaniel Nystrom. Jif: Java information flow. Software release. 0968. Any opinions, findings, conclusions, or recommenda- Located at http://www.cs.cornell.edu/jif, July 2001–2003. tions contained in this material are those of the authors and [18] Jens Palsberg and Peter Ørbæk. Trust in the λ-calculus. In Proc. do not necessarily reflect views of the Office of Naval Re- 2nd International Symposium on Static Analysis, number 983 in Lec- search. This work was also supported by the National Sci- ture Notes in Computer Science, pages 314–329. Springer, September ence Foundation under grants 0208642 and 0133302, and by 1995. an Alfred P. Sloan Research Fellowship. [19] François Pottier and Vincent Simonet. Information flow inference for ML. In Proc. 29th ACM Symp. on Principles of Programming Languages (POPL), pages 319–330, 2002.

10 [20] Andrei Sabelfeld and Heiko Mantel. Static confidentiality enforce- (v | void) and mτ 7→ (void | v) represent situations where ment for distributed programs. In Proceedings of the 9th International τ m is bound within only one of the two λDSec memories. Static Analysis Symposium, volume 2477 of LNCS, Madrid, Spain, September 2002. Springer-Verlag. ` ::= ... | (` | `) [21] Andrei Sabelfeld and Andrew Myers. Language-based information- v ::= ... | (v | v) | void flow security. IEEE Journal on Selected Areas in Communications, 21(1):5–19, January 2003. e ::= ... | (e | e) [22] Ravi S. Sandhu and Sushil Jajodia. Honest databases that can keep The bracket constructs cannot be nested, so the subterms of secrets. In Proceedings of the 14th National Computer Security Con- ference, Washington, DC, 1991. a bracket construct must be λDSec terms or void. Given 2 [23] Ian Sutherland, Stanley Perlo, and Rammohan Varadarajan. De- a λDSec expression e, let bec1 and bec2 represent the two ducibility security with dynamic level assignments. In Proc. 2nd λDSec terms that e encodes. The projection functions sat- IEEE Computer Security Foundations Workshop, Franconia, NH, isfy b(e1 | e2)ci = ei and are homomorphisms on other June 1989. expression forms. In addition, (e1 | e2)[v/x], the capture- [24] Stephen Tse and Steve Zdancewic. Run-time principals in free substitution of v for x in (e1 | e2), must use the corre- information-flow type systems. In IEEE Symposium on Security and sponding projection of v in each branch: (e | e )[v/x] = Privacy, Oakland, CA, May 2004. 1 2 (e1[bvc1/x] | e2[bvc2/x]). [25] Dennis Volpano, Geoffrey Smith, and Cynthia Irvine. A sound type 2 system for secure flow analysis. Journal of Computer Security, In λDSec, labels can be bracket constructs, and types 4(3):167–187, 1996. may contain bracketed labels. Thus, the projection opera- [26] Clark Weissman. Security controls in the ADEPT-50 time-sharing tion can be applied to labels, types, type assignments, and system. In AFIPS Conference Proceedings, volume 35, pages 119– label constraints. Similarly, the projection functions are 133, 1969. homomorphisms on these typing constructs. For example, 0 [27] John P. L. Woodward. Exploiting the dual nature of sensitivity labels. bint(L | H)c1 = intL, and bx : τ, y : τ c1 = x : bτc1, y : In IEEE Symposium on Security and Privacy, pages 23–30, Oakland, 0 bτ c1. California, 1987. The following relabeling rule is added to reason about [28] Hongwei Xi. Imperative programming with dependent types. In Pro- relabeling relationship between bracketed labels: ceedings of 15th Symposium on Logic in Computer Science, Santa Barbara, June 2000. bCc1 ` b`1c1 v b`2c1 bCc2 ` b`1c2 v b`2c2

[29] Hongwei Xi and Frank Pfenning. Dependent types in practical pro- C ` `1 v `2 gramming. In Proc. 26th ACM Symp. on Principles of Programming Languages (POPL), pages 214–227, San Antonio, TX, January 1999. [30] Steve Zdancewic and Andrew C. Myers. Secure information flow via 2 Since a λDSec term effectively encodes two λDSec terms, linear continuations. Higher Order and Symbolic Computation, 15(2– the evaluation of a λ2 term can be projected into two 3):209–234, September 2002. DSec λDSec evaluations. An evaluation step of a bracket expres- [31] Steve Zdancewic and Andrew C. Myers. Observational determinism (e | e ) e e for concurrent program security. In Proc. 16th IEEE Computer Secu- sion 1 2 is an evaluation step of either 1 or 2. and rity Foundations Workshop, pages 29–43, Pacific Grove, California, e1 or e2 can only access the corresponding projection of 2 June 2003. the memory. Thus, the configuration of λDSec has an index [32] Lantian Zheng and Andrew C. Myers. Dynamic security labels and i ∈ {•, 1, 2} that indicates whether the term to be evaluated noninterference. Technical Report 2004–1924, Cornell University is a subterm of a bracket expression, and if so which branch Computing and Information Science, 2004. of a bracket the term belongs to. For example, the configuration he, Mi1 means that e belongs to the first branch of A Subject Reduction Proof a bracket, and e can only access the first projection of M. We write “he, Mi” for “he, Mi•”, which means e does not As described in Section 4.4, the noninterference result for belong to any bracket. λDSec is proved by extending the language to a new lan- 2 guage λDSec that includes the special bracket construct. 2 A.2 Operational semantics Then the subject reduction property for λDSec implies the 2 noninterference property for λDSec. The appendix details The operational semantics of λDSec is shown in Figure 6. It 2 the syntax and semantic extensions of λDSec and proves the is based on the semantics of λDSec and contains some new key subject reduction theorem. evaluation rules (E10–E14) for manipulating bracket constructs. Rules (E2)–(E4) are modified to access the memory A.1 Syntax extensions projection corresponding to index i. The rest of the rules in Figure 2 are adapted to λ2 by indexing each configura- 2 DSec The syntax extensions of λDSec include the bracket con- tion with i. The following two lemmas state that the opera- structs and a new value void that can have any type. A tional semantics of λ2 is adequate to encode the execu- 2 DSec λDSec memory encodes two λDSec memories, which may tion of two λDSec terms. Their proof is straightforward. have distinct domains. The bindings of the form mτ 7→

11 Lemma A.1 (Soundness). If he, Mi 7−→ he0,M 0i, then Theorem A.1 (Subject Reduction). Suppose pc ` e : τ, 0 0 0 0 hbeci, bMcii 7−→ hbe ci, bM cii for i ∈ {1, 2}. memory M is well-typed, he, Mii 7−→ he ,M ii, and i ∈ 0 0 ∗ {1, 2} implies H v pc. Then pc ` e : τ, and M is also Lemma A.2 (Completeness). If hbeci, bMcii 7−→ 0 well-typed. hvi,Mi i for i ∈ {1, 2}, then there exists a conﬁguration 0 ∗ 0 hv, M i such that he, Mi 7−→ hv, M i. Proof. By induction on the derivation of he, Mii 7−→ he0,M 0i . Without loss of generality, we assume that the The type system of λ2 includes all the typing rules in i DSec last step of the derivation of pc ` e : τ does not use the Figure 5 and has two additional rules, one for typing void, rule (SUB). Here we just show eight cases: (E3), (E5), (E6), the other for typing bracket constructs. (E8), (E10), (E11), (E14) and (E16). The rest of evaluation rules are treated similarly. [VOID]Γ; C ; pc ` void : τ τ 0 0 0 • Case (E3). e is ref v, and τ is (τ ref)⊥. Then e is 0 τ 0 0 0 bΓc1 ;bCc1 ;bpc c1 ` e1 : bτc1 m . By (LOC), pc ` e :(τ ref)⊥. By Lemma A.6, 0 0 τ 0 bΓc2 ;bCc2 ;bpc c2 ` e2 : bτc2 pc ` newiv : τ . Thus, M[m 7→ newiv] is well-typed. H t pc v pc0 H v τ [BRACKET] • Case (E5). e is (λ(x : τ 0)[C0 ; pc0]. e0)v. Then pc ` Γ; C ; pc ` (e1 | e2): τ 00 00 0 0 0 0 00 C ; pc λ(x : τ )[C ; pc ]. e : ((x : τ ) −−−−−→ τ1)`, and pc ` v : τ 00, and ` C00[v/x]. By rules (APP) and 00 A.3 Subject reduction (L-APP), τ = τ1[v/x] t `, and pc v pc [v/x]. By 0 0 0 0 rules (ABS) and (SUB), x : τ ; C ; pc ` e : τ1, The proof of subject reduction starts with some lemmas and ` τ 00 ≤ τ 0, ` pc00 v pc0, and C00 ` C0. There- about projection and substitution. fore, ` C0[v/x], and pc v pc0[v/x]. By the substitu- 0 0 0 tion lemma, C [v/x]; pc [v/x] ` e [v/x]: τ1[v/x]. By Lemma A.3 (Label Projection). If C ` `1 v `2, then 0 0 Lemma A.4, pc [v/x] ` e [v/x]: τ1[v/x]. Since pc v bCci ` b`1ci v b`2ci for i ∈ {1, 2}. 0 0 pc [v/x] and τ1[v/x] v τ, we have pc ` e [v/x]: τ. Proof. By induction on the derivation of C ` `1 v `2. • Case (E6). By rule (IF), k1 v k2 ; pc ` e1 : τ. By

Lemma A.4 (Constraint Reduction). If Γ; C, `1 v Lemma A.4 and L |= k1 v k2, we have pc ` e1 : τ. `2 ; pc ` e : τ and C ` `1 v `2, then Γ; C ; pc ` e : τ. 0 • Case (E8). e is let (x, y) = (x = v1[C], v2 : τ2) in e . By rule (UNPACK), pc ` (x = v [C], v : τ ): Proof. By induction on the derivation of Γ; C, `1 v 1 2 2 ((x : τ )[C] ∗ τ ) , and x : τ t `, y : τ t ` ; pc ` `2 ; pc ` e : τ. 1 2 ` 1 2 0 e : τ. By rule (PROD), pc ` v1 : τ1[v1/x], and Lemma A.5 (Projection). If Γ; C ; pc ` e : τ, then pc ` v2[v1/x]: τ2[v1/x], and ` C[v1/x]. Using bΓci ;bCci ;bpcci ` beci : bτci, for i ∈ {1, 2}. the substitution lemma twice, we get C[v1/x]; pc ` 0 e [v1/x][v2[v1/x]/y]: τ[v1/x][v2[v1/x]/y]. It is easy Proof. By induction on the derivation of Γ; C ; pc ` e : τ, 0 0 to show that e [v1/x][v2[v1/x]/y] = e [v2/y][v1/x]. and using the label projection lemma. According to rule (UNPACK), x, y 6∈ FV (τ). Thus, Lemma A.6 (Store Access). Let i be in {•, 1, 2}. Suppose τ[v1/x][v2[v1/x]/y] = τ. In addition, we have ` pc ` v : τ and pc ` v0 : τ. In addition, i ∈ {1, 2} implies C[v1/x]. Therefore, pc ` e[v1/x][v2/y]: τ. H v τ. Then pc ` readi v : bτci, pc ` newi v : τ and • e (e | e ) 0 Case (E10). is 1 2 . Without loss of generality, pc ` updatei vv : τ. 0 0 0 assume he1,Mi1 7−→ he1,M i1 and e2 = e2. By rule Proof. By the deﬁnition of the functions read, new and (BRACKET), H v pc, and bpcc1 ` e1 : bτc1. H v pc 0 update in Figure 6, by the projection lemma, and rules implies H v bpcc1. By induction, bpcc1 ` e1 : bτc1, 0 (VOID) and (BRACKET). and M is well-typed. Using rule (BRACKET), we can 0 0 get pc ` (e1 | e2): τ. Lemma A.7 (Substitution). If x : τ 0, Γ; C ; pc ` e : τ, 0 • Case (E11). e is (v1 | v2)v. By (APP) and (L-APP), and ` v : τ [v/x], then Γ[v/x]; C[v/x]; pc[v/x] ` e[v/x]: 0 0 0 C ; pc 00 0 τ[v/x]. pc ` (v1 | v2) : ((x : τ ) −−−−→ τ )`, and pc ` v : τ . Then τ = τ 00[v/x] t `. In addition, pc t ` v pc0. By 0 Proof. By induction on the derivation of x : τ , Γ; C ; pc ` (BRACKET), H v `, which implies H v pc0. By e : τ. 0 0 0 bC ci ;bpc ci Lemma A.5, bpcci ` vi : ((x : bτ ci) −−−−−−−−→ 0 bτci)b`ci , and bpcci ` bvci : bτ ci, which imply

12 τ τ [E2] h!m ,Mii 7−→ hreadi M(m ),Mii

m 6∈ address-space(M) [E3] τ τ τ href v, Mii 7−→ hm ,M[m 7→ newi v]ii

τ τ τ [E4] hm := v, Mii 7−→ h(),M[m 7→ updatei M(m ) v]ii

0 0 0 hei,Mii 7−→ hei,M ii ej = ej {i, j} = {1, 2} [E10] 0 0 0 h(e1 | e2),Mi 7−→ h(e1 | e2),M i

[E11] h(v1 | v2)v, Mi 7−→ h(v1bvc1 | v2bvc2),Mi

[E12] h(v1 | v2) := v, Mi 7−→ h(v1 := bvc1 | v2 := bvc2),Mi

[E13] h!(v1 | v2),Mi 7−→ h(!v1 | !v2),Mi

[E14] hif v1 v v2 then e1 else e2,Mi 7−→ h(if bv1c1 v bv2c1 then be1c1 else be2c1 | if bv1c2 v bv2c2 then be1c2 else be2c2),Mi 0 0 if v1 = (v | v ) or v2 = (v | v )

0 0 [E15] hv1 t v2,Mi 7−→ h(bv1c1 t bv2c1 | bv1c2 t bv2c2),Mi if v1 = (v | v ) or v2 = (v | v )

0 0 0 0 0 0 [E16] hlet (x, y)=((x=v1[C], v2 :τ) | (x=v1[C ], v2 :τ )) in e, Mi 7−→ he[(v2 | v2)/y][(v1 | v1)/x],Mi

[Auxiliary functions]

0 0 new• v = v update• vv = v read• v = v 0 0 new1 v = (v | void) update1 vv = (v | bvc2) read1 v = bvc1 0 0 new2 v = (void | v) update2 vv = (bvc1 | v ) read2 v = bvc2

2 Figure 6: Small-step operational semantics of λDSec

bpcci ` vibvci : bτci. According to (APP) and (L- APP), a well-typed application expression e1e2 can be type-checked with the pc component of the type of e1 in 0 the typing context. Therefore, bpc ci ` vibvci : bτci. Since H v pc0, we can apply (BRACKET) to get pc ` (v1bvc1 | v2bvc2): τ.

• Case (E14). e is if v1 v v2 then e1 else e2, and 0 there exists j ∈ {1, 2} such that vj = (v | v ). Suppose

pc ` vi : label`i for i ∈ {1, 2}. Since vj is a bracket construct, H v `j. By (IF), both e1 and e2 are type- checked with pc t `1 t `2 in the typing context. Thus, we can get pc t `1 t `2 ` e : τ. By Lemma A.5, bpc t `1 t `2ci ` beci : bτci. H v `j implies H v bpc t `1 t `2ci. Applying (BRACKET), we get pc ` (bec1 | bec2): τ.

• Case (E16). e is let (x, y) = ((x = v1[C], v2 : 0 0 0 0 0 τ) | (x = v1[C ], v2 : τ )) in e . Suppose expression 0 0 0 0 ((x = v1[C], v2 : τ) | (x = v1[C ], v2 : τ )) has type 0 (x:τ1)[C0] ∗ τ2)⊥. It is easy to show that (v1 | v1) and 0 (v2 |v2) have type τ1 and τ2 respectively. Then this case is reduced to case (E8), which is standard.