A Type System for Data-Flow Integrity on Windows Vista

A T ype System f or Data-Flow Integrity on W indows V ista A vik Chaudhuri Univ ersity of California at Santa Cruz avik@cs .u csc.edu Prasad Naldurg Sriram Rajamani Microsoft Research India { prasadn,sri ram } @microsoft.com Abstract The W indows V ista operating system implements an interesting model of multi-lev el integrity . W e obse r ve that in t his model, trusted code can be blamed for any information-ﬂow attack; thus, it is possible to eli minate such attacks by static analysis of trusted code. W e formalize this model by designing a type system that can efﬁcien tly en force data-ﬂo w integrity on W indo ws V ista. T ype- checking guarantees that objects whose contents are statically trusted n ever contain untrusted v alues, re gardless of what untrusted code runs in the en vironment. Some of Windo ws V ista’ s runtime access checks are necessary for soundness; others are redundant and can be optimized away . Categories and Subject Descriptors D.4.6 [ Operating Systems ]: Security and Protection—Access controls, Information ﬂow con- trols, V eriﬁcation; D.2.4 [ Software Engineering ]: Program V erif- ication—Correctness proofs; F .3.1 [ Logics and Meanings of P r o- grams ]: Specifying and V erifying and Reasoning about Programs— Speciﬁcation techniques, In variants, Mecha nical veriﬁcation General T erms Security , V eriﬁcation, Langu ages, Theory Key words dynamic access control, data-ﬂo w integ r ity , hybrid type system, exp l icit substitution 1. Introduction Commercial operating systems are seldom designed to prev ent information-ﬂo w attacks. Not surprisingly , such attacks are the source of many serious security problems in these systems [44] . Microsoft’ s Wind ows V ista operating system implements an in- tegrity model that can potentially prev ent such attacks. In some ways, this model resembles other , classical models of multi-lev el integrity [9]—e very process and object 1 is tagged with an inte grit y label, the labels are ordered by lev els of tr ust, and access control is enforced across t rust boundaries. In other ways, it is radically differe nt. W hile Windo ws Vista’ s access control prev ents low- integrity processes from writing to high-integ r ity objects, it does not prev ent high-integrity processes from r eading low-inte grity objects. F urther , Windo ws V ista’ s integrity l abels are dynamic— labels of processes and objects can change at runtime. This model 1 In th is conte xt, an ob ject may be a ﬁle, a channel, a memory location , or indeed any refe rence to data or ex ecutable code. Permission to make digital or hard copies of all or part of this work for personal or classroom us e is granted without fee provided that c opies are not made or dis tribut e d for proﬁt or commer c ial advantage and that copies bear this notice and the f ull citation on the ﬁrst page. T o copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speciﬁc permission and/or a fee. PLAS’08, June 8, 2008, Tucson, Arizona, USA. Copyright c  2008 ACM 978-1- 59593-936-4/08/06. . . $5.00 allows processes at differen t trust lev els to communicate, and al- lo w s dynamic access control. At t he same time, it admits various information-ﬂo w attacks. Fortunately , it turns out that such attacks require the participation of trusted processes, and can b e eliminated by code analysis. In this paper , we provide a formalization of W indows Vista’ s in- tegrity model. In particular , we specify an information-ﬂow prop- erty called data-ﬂow inte grity (DFI), and present a st atic t ype sys- tem that can enforce DFI on Windo ws V ista. Roughly , DFI pre vents any ﬂ o w of data from the en vironment to objects whose contents are trusted. Our type sy stem relies on W indows V ista’ s run ti me ac- cess checks for soundness. T he key idea in the type system is to maintain a static lower -bound label S for each object. While the dynamic l abel of an object can change at runtime, the type system ensures that it ne ver goes belo w S , and the object nev er contains a v alue that ﬂ o ws from a label lower than S . The label S is declared by the programmer . T ypechecking r equires no other annotations, and can be mechanized by an ef ﬁ cient algorithm. By design, DFI does not prev ent implicit ﬂows [18]. Thus DFI is weaker than noninterference [23]. Unfortunately , it is difﬁcult to enforce noninterference on a commercial operating system such as Win dows V ista. Implicit ﬂ o ws abound in such systems. Such ﬂows arise out of frequent, necessary interactions between trusted code and the environ ment. T hey also arise out of cov ert control channels which, giv en the scope of such systems, are impossible to model sufﬁciently . Instead, DFI f ocuses on explicit ﬂows [18 ]. This focus b uys a reasonable compromise—DFI pre vents a deﬁnite class of attacks, and can be enforced ef ﬁciently on Windo ws V ista. Sev eral suc cessful tools for malw are detection follow this approach [12, 52, 47, 49, 16, 37], and a simil ar approach guides the design of some recent operating systems [19, 57]. Our deﬁnition of DF I is dual to standard deﬁnitions of secrecy based on explicit ﬂows—while secrecy pre vents sensitive values from ﬂowing to the env ir onment, DFI pre vents the ﬂow of values from the env i ronment to sensitiv e objects. Si nce there is a rich lit er- ature o n type-based and log i c-based analysis for such deﬁnitions of secrecy [11, 3, 48, 13], it mak es sense to adapt this analysis for DFI. Such an adaptation works, but requires some care. Unlike secrecy , DFI cannot be enforced without runtime checks. In particular, ac- cess checks play a crucial role by restricting untrusted processes that may run in the en vironment. Further, while secrecy pre vents any ﬂow of high-security information to the en vironment, DFI al- lo w s certain ﬂows of low-se curity information f rom the en viron- ment. W e need to introd uce new technical de vices for this purpo se, including a technique based on e xplicit substitution [4] to track p r e- cise sources of values. This device is required not only to specify DFI precisely bu t also to prov e that our type system enforces DF I. W e design a simple higher-order process calculus that simu- lates Wind ows V ista’ s security en vironment [31, 17, 43]. In this language, processes can fork ne w processes, create new objects, change the labels of processes and objec t s, and read, write, a nd ex- ecute objects in exactly the same ways as Windo ws Vista allows. Our type system exploits Windo ws V ista’ s runtime access checks to enforce DFI, and can r ecognize many correct programs. At the same time, our t ype system subsumes W indows V i sta’ s exec uti on controls, allo wi ng them to be optimized aw ay . 1.1 Summary of contributions T o sum up, we make the following main co ntri bution s in this paper: • W e propose DFI as a practical multi-lev el integrity property in the setting of Wind ows V ista, and formalize DFI using a semantic technique based on explicit sub sti tution. • W e present a type system that can ef ﬁ ciently enforce DFI on W indows V i sta. T ypeche cking guarantees DFI regardless of what untrusted code runs in the en vironment. • W e sho w that while most of Windo ws V i sta’ s runtime access checks are required to enfo r ce DFI, W indows V ista’ s e xecution controls are redundan t and can be optimized away . 1.2 Outline The rest of this paper is organized as follo ws. In Section 2, we introduce Windo ws V ista’ s security en vironment, and sho w ho w DFI may be violated in that env i ronment. In Section 3, we design a calculus that simulates W indows V ista’ s security env i ronment, equip the calculus with a semantics based on explicit substitution, and f ormalize DFI in the calculus. In Section 4, we present a system of integrity types and ef fects f or this calculus. In Section 5, we prove soundness and other properties of t yping. F inally , in Section 6, we discuss limitati ons and contributions with respect to related work and conclude. Supplementary material, including proof details and an ef ﬁcient typech ecking algorithm, appear in the appendix. 2. W indows Vi s ta’ s integrity model In this section, w e provide a brief overvie w of Windo ws V ista’ s integrity model. 2 In particular , we introduce W indows V ista’ s se- curity en vironment, and show ho w DFI may be violated in that en- vironment. W e observe that such att acks require t he participation of trusted processes. 2.1 Windows V ista’ s security envir onment In W indows Vista, ev ery process and object is tagged with a dy- namic integrity label. W e indicate such labels in brack ets ( ) belo w . Labels are related by a total order ⊑ , meaning “at most as trusted as”. Let a range ov er processes, ω over objects, and P , O ov er la- bels. Processes can fork ne w processes, create ne w objects, change the labels of processes and objects, and read, write, and execute objects. In particular , a process with label P can: (i) fork a ne w process a ( P ) ; (ii) create a new object ω ( P ) ; (iii) lower its o wn label; (iv) change t he label of an object ω ( O ) to O ′ iff O ⊔ O ′ ⊑ P ; (v) read an object ω ( O ) ; (vi) write an object ω ( O ) i f f O ⊑ P ; (vii) ex ecute an object ω ( O ) by lo wering its o wn label to P ⊓ O . Rules (i ) and (i i) are straightforward. Rule (iii) is guided by the principle of least privilege [34], and is used in Wind ows Vista to implement a feature called user access contro l (UA C) [43]. This feature lets users execute commands with lower privile ges when 2 W indows V ista further implements a discreti onary access control model, which we ignore in this paper . appropriate. For example, when a system administrator opens a ne w shell (typ i cally with label High ), a ne w process is forked with label Medium ; t he shell is then run by the ne w proc ess. When an Internet bro wser i s opened, it is always run by a new process whose l abel is lowered to L o w ; t hus any code that gets run by t he browser gets the lab el Low —by Rule (i)—and any ﬁle that is downloaded b y the bro wser gets the label Low —by Rule (ii). Rules (iv ) and (v) are useful in v ari ous ways, but can be dan- gerous if not used carefully . ( W e sho w some attacks to illustrate this point belo w .) In particular, Rule (iv) allows unprotected ob- jects to be protected by trusted processes by raising their labels, and Rule (v) allows processes to read objects at lower trust lev els. At the same time, Rule (iv) facilitates dynamic access control, and Rule (v) facilitates commun icati on across trust boundaries. Rule (vi) protects objects from being written by processes at lo w er trust lev el s. Thus, for example, untrusted code f orked by a bro wser cannot affect local user ﬁ les. User code cannot modify registry keys protected by a system administrator . Rule (vii) i s part of UA C; it prev ents users from accidentally launching less trusted exec utables with higher privile ges. For examp l e, a virus do wnloaded from the Internet cannot run in a trusted user shell. Neither can system code dynamically link user libraries. 2.2 Some attacks W e now show some att acks that remain possible in this en viron- ment. Basically , these attacks exploit Rules (iv) and (v) to bypass Rules (vi) and (vii). ( Write and copy ) By Rule ( vi), a ( P ) cannot modify ω ( O ) if P ⊏ O . Ho wever , a ( P ) can modify some object ω ′ ( P ) , and then some process b ( O ) can copy ω ′ ( P ) ’ s content to ω ( O ) . T hus, Rule (iv) can be exploited to byp ass Rule (vi). ( Copy and execute ) By Rule (vii), a ( P ) cannot execu t e ω ( O ) at P i f O ⊏ P . Howe ver , a ( P ) can copy ω ( O ) ’ s content to some object ω ′ ( P ) and then exec ute ω ′ ( P ) . Thus, Rule (iv) can be exploited to by pass Rule (vii). ( Unprotect, write, and pr otect ) By Rule (vi), a ( P ) cannot mod- ify ω ( O ) if P ⊏ O . Ho wev er , some process b ( O ) can unprotec t ω ( O ) to ω ( P ) , then a ( P ) can modify ω ( P ) , and then b ( O ) can protect ω ( P ) back to ω ( O ) . T hus, Rule (v) can be exploited t o bypass Rule (vi). ( Copy , protect, a n d execute ) By Rule (vii), a ( P ) cannot exe cute ω ( O ) at P if O ⊏ P . Howe ver , some process b ( O ) can copy ω ( O ) ’ s content t o an object ω ′ ( O ) , and then a ( P ) can protect ω ′ ( O ) to ω ′ ( P ) and e xecute ω ′ ( P ) . Th us, Rules (iv) and (v) can be exp l oited to bypass Rule (vii). Next, we sho w that all of these attacks can violate D FI. At the same time, we observe that access control forces the participation of a trusted process (one with the higher label) in any suc h attack. • In ( Write and copy ) or ( Unp rotec t, write, and p rotect ), sup- pose that the contents of ω ( O ) are trusted, and P is the label of untrusted code, wi th P ⊏ O . Then data can ﬂ o w from a ( P ) t o ω ( O ) , violating DFI, as abov e. Fortunately , some process b ( O ) can be blamed here. • In ( Copy and execute ) or ( Copy , protect, and execute ), sup- pose that the contents of some object ω ′′ ( P ) are t rusted, and O is the label of untrusted code, with O ⊏ P . Then data can ﬂ o w from some process b ( O ) t o ω ′′ ( P ) , violating DFI, as follows: b ( O ) packs cod e to modify ω ′′ ( P ) and writes the code to ω ( O ) , and a ( P ) unpacks and ex ecutes that code, as abov e. Fortunately , a ( P ) can be blamed here. Our type system can eliminate such attacks by restricti ng trusted processes (Section 4). (Obviously , the type system cannot restrict untrusted code running in the env ir onment.) Conceptually , this guarantee can be cast as W adler and Fi ndler’ s “ well-typed pr ograms can’ t be blamed ” [51]. W e rely on the fact t hat a trusted process can be blamed for a ny violation of DFI; it follo ws that if all trusted processes are well-typed, there cannot be any violation of DFI. 3. A calculus f or analyzing DFI on Windows Vi s ta T o formalize our approach, we no w design a simple higher-order process calculus that simulates Windo ws V i sta’ s security en viron- ment. W e ﬁrst introduce the syntax and informal semantics, and present some examples of programs and attacks in the language. W e then present a formal semantics, guided by a precise cha racter- ization of explicit ﬂo ws. 3.1 Syntax and informal sema n tics Sev eral simpliﬁcations appear in the syntax of the language. W e describe pro cesses by the i r code. W e use v ariables as ob j ect n ames, and let objects contain packed code or names of other objects. W e enforce a mild syntactic restriction on nested packing, which makes typechecking signiﬁcantly more efﬁcient (Appendix B; also see belo w). F inally , we elide conditionals—for our purposes, the code if condition then a else b can be conserv atively analyzed by composing a and b in parallel. (DFI is a safety pro perty in the sense of [7], and the safety of the latter cod e implies that of t he former . W e discuss th i s point in more detail in Section 3.3.) V alues include v ariables, unit , and pack ed expressio ns. E xpres- sions include those for forking n ew processes, creating new objects, changing the labels of processes and objects, and reading, writing, and executing objects. They also include standard expressions for e valuation and returning results (see Gordon and Hankin’ s concur- rent object calculus [24]). f , g ::= express ion f  g fork t action let x = f in g e valuation r result t ::= action new ( x # S ) create object [ P ] a change process label h O i ω change object label ! ω read object ω := x write object exec ω ex ecute object r ::= result x, y , z , . . . , ω v ariable unit unit a, b ::= process a  b fork t action let x = a in b e valuation u v alue u, v ::= v alue r result pack ( f ) packe d expression Syntactically , we disti nguish between processes and expressions: while ev ery expression is a process, not e very process is an ex- pression. For examp l e, the process p ack ( f ) is not an expression, although the process [ P ] p ack ( f ) is. Expressions can be packe d, but processes in general cannot. In particular , a process cannot be of the f orm pack ( pack ( . . . ) ) . (Such a process can, howe ver , be written as let x = pack ( . . . ) in pack ( x ) . ) The beneﬁts of t his dis- tinction become cl ear in S ection 5, where we discuss mechanical typechecking . Ho wever , for the bulk of the paper , the reader may ignore this distinction; indeed, neither the semantics nor the type system are af fected by t his distinction. Processes hav e the following informal meanings. • a  b forks a new process a with the current process label and continues as b (see R ule (i)). • new ( x # S ) creates a new object ω with the current process label, init ializes ω w ith x , and returns ω (see Rule (ii) ); the annotation S is used by the type system (Section 4) and has no runtime signiﬁcance. • [ P ] a changes the current process label to P and continues as a ; it blocks if the current process label is lo wer than P (see Rule (iii)). • h O i ω changes ω ’ s label to O and r eturns unit ; it blocks if ω i s not bound to an object at runtime, or the current process label is lo wer than ω ’ s label or O (see Rule (iv)). • ! ω returns the value stored in ω ; i t blocks if ω is not bound to an object at runtime (see Rule (v)). • ω := x writes the value x to ω and returns un it ; it block s if ω is not bound to a n object at runtime, or if the current process lab el is lo wer than ω ’ s label (see Rule (vi)). • exec ω unpacks the valu e stored in ω to a process f , lowers the current proce ss label with ω ’ s label, an d executes f ; it blocks if ω is not bound to an object at runtime or if the v alue stored in ω is not a pack ed expression (see Rule (vii)). • let x = a in b exec utes a , binds the value returned by a to x , and continues as b with x bound . • u returns itself. 3.2 Programm i ng examples W e now consider some programming examples in the language. W e assume that Low , Med ium , High , and ⊤ are labels, ordered in the obvio us way . W e assume that the top-le vel process alway s runs with ⊤ , which is the most trusted label. Example 3.1. Suppose that a Medium user opens an Internet bro wser ie . exe with L o w privileges (recall UA C), and clicks on a url that contains virus . exe ; t he virus contains code to ov erwr ite the command shell ex ecutable cmd . exe , which has label ⊤ . p 1 , let cmd . exe = new ( . . . # ⊤ ) in let url = [ Lo w ] new ( . . . # Low ) in let binIE = pack ( let x = ! url in exec x ) in let ie . exe = new ( binIE # ⊤ ) in [ Medium ] ( . . .  [ Low ] exec ie . exe )  [ Lo w ] ( let binVirus = pack ( cmd . exe := . . . ) in let virus . exe = n ew ( binVirus # Low ) in url := virus . exe  . . . ) This code may e ventually reduce to q 1 , [ Medium ] ( . . .  [ Low ] cmd . exe := . . . )  [ Lo w ] ( . . . ) Ho wever , at this point the write to cmd . exe blocks due to access control. ( Recall that a process w ith label L o w cannot write to an object with label ⊤ .) Example 3.2. Next, consider t he following attack, based on the ( Copy , protect, and execute ) attack in Section 2.2. A Mediu m user do wnloads a virus f rom the Internet that contains code t o erase the user’ s home directory ( home ) , and sa ves it by def ault in setup . exe . A High administrator protects and ex ecutes setup . exe . p 2 , let url = [ Lo w ] new ( . . . # Low ) in let setup . exe = [ Lo w ] new ( . . . # Low ) in let binIE = pack ( let z = ! url in let x = ! z in setup . exe := x ) in let ie . exe = n ew ( binIE # ⊤ ) in let home = [ Medium ] new ( . . . # Medium ) in let empty = unit in [ High ] ( · · ·  let = h High i setup . exe in exec setup . e xe )  [ Medium ] ( . . .  [ Lo w ] exec ie . exe )  [ Lo w ] ( let binVirus = p ack ( home := empty ) in let virus . exe = new ( binVirus # Low ) in url := virus . exe  . . . ) This code may ev entually reduce to q 2 , [ High ] ( . . .  home := empty )  [ Medium ] ( . . . )  [ Lo w ] ( . . . ) The user’ s home directory may be erased at this point. (Recall that access control does not prev ent a process with label High from writing to an object with label Medium .) 3.3 An ov erview of DF I Informally , DF I requires that objects whose contents are trusted at some label S never contain values that ﬂow from labels l o wer than S . In Example 3.1, we trust t he contents of cmd . exe at label ⊤ , as declared by the static annotation ⊤ . DF I is not violated in t his examp l e, since access control prev ents the ﬂow of d ata from Low to cmd . exe . On the other hand, i n Example 3.2, we t rust the contents of h ome at label Med ium . DFI is violated in this example, since the v alue empty ﬂ o ws f rom Lo w to home . By design, DFI is a safety property [7]—roughly , it can be deﬁned as a set of behaviors such t hat for any behavior t hat not in that set, there is some ﬁnite preﬁx of that beha vior that is n ot in that set. T o that end, DFI considers only explicit ﬂows of data. Den ning and Denning characterizes explicit ﬂows [18] r oughly as follo ws: a ﬂ o w of x is explicit if and only if the ﬂ o w depends abstractly on x (that is, it depends on the existence of x , but not on the v alue x ). Thus, for examp l e, the violation of DFI in Example 3.2 does not depend on the v alue empty — any other value causes the same violation. Con versely , empty is not dangerous in itself. Consider the reduced process q 2 in Example 3.2. Without any kno wledge of ex ecution history , we cannot conclude that DFI is violated in q 2 . Indeed, it is perfectly legitimate for a High -process to ex ecute the code home := empty intentionally , say as part of administration. Howe ver , in Exam- ple 3.2, we kno w that this code is executed by unpacking some code designed by a Low -process. The violation of DF I is due to this history . It follo ws t hat in order to detect violations of DFI, we must dis- tinguish between v arious instances of a value , and track the sources of those instances during execution. W e maintain this exec ution history in the operational semantics (S ection 3.4), by a technique based on exp l icit substitution [4]. Before we move on, let us ease t he tension between DFI and conditionals. In general, conditiona l s can cause implicit ﬂows [18]; a ﬂow of x can depend on the v alue x if x appears in the condition of some code that causes that ﬂo w . For example, the code if x = zero then ω := zero else ω := one causes an implicit ﬂow of x t o ω that depends on the value x . W e can abstract away this dependenc y by interpreting the code if condition then a else b as the code a  b . Recall that DFI is a safety property . Follo wing [33 ] , the safety of a  b can be expressed by the logical formula F , F a ∧ F b , where F a is the formula that express es the safety of a , and F b is the formula t hat expresses t he safety of b . Like wise, t he safety of if cond ition then a else b can be expressed by the formula F ′ , ( conditio n ⇒ F a ) ∧ ( ¬ condition ⇒ F b ) . Clearly , we have F ⇒ F ′ , so that the code if condition th en a else b is a reﬁnement of the code a  b . It is well-kno wn that safety is preserv ed under reﬁnement [33]. But i mplicit ﬂows are of serious concern i n many applications; one may wonder whether focusing on explicit ﬂ o ws is ev en desir- able. Consider the code abov e; t he implicit ﬂow from x to ω vio- lates noninterference, if x is an untrusted va l ue and the contents of ω are trusted. In contrast, DFI is not v iolated in t he interpreted co de ω := zero  ω := one if zero and one are trusted v alues. Clearly , DF I ignores the implicit ﬂow from x to ω . But this may be ﬁne—DFI can be used to prove an in variant such a s “the contents of ω are alw ays boolean v alues”. Note that the code ω := x does not maintain this inv ariant, since x may be an arbitrary value. Thankfully , DF I is violated in this code. 3.4 An operational semantics that tracks explicit ﬂows W e no w present a chemical-style operational semantics for the language, that tracks explicit ﬂ o ws. 3 W e beg in by extending the syntax with some auxiliary forms. a, b ::= process · · · source process ω O 7→ x store ( ν x/µ @ P ) a explicit su bstit ution µ ::= substituted v alue u v alue new ( x # S ) object initialization The process ω O 7→ x asserts that the object ω contains x and is protected with label O . A key feature of the semantics is that objects store values “by instance”—only variables may appear in stores. W e use explicit substitution to track and distinguish between the sources o f various instances of a s ubstituted v alue. Speciﬁcally , the process ( ν x/µ @ P ) a creates a f resh variab l e x , records that x is bound to µ by a process with label P , and continues as a wit h x bound. Here x is an instance of µ and P is the source of x . If µ is a value, then this process is beha viorally equiv alent to a with x substituted by µ . For example, in Example 3.2 the source of the instance of empty in binVirus is Low ; this fact is described by 3 This presentat ion is particul arly con venien t for deﬁning and proving DFI; of course, a concrete implementatio n of the languag e may rely on a lighter semantic s that does not track explicit ﬂows. Local reduction a P ; σ − → b p ( Reduct ev alu ate ) let x = u in a P ; σ − → ( ν x/u @ P ) a ( Reduct new ) new ( x # S ) P ; σ − → ( ν ω / new ( x # S ) @ P ) ( ω P 7→ x  ω ) ( Reduct read ) ω σ = ω ′ ω O 7→ x  ! ω ′ P ; σ − → ω O 7→ x  x ( Reduct write ) ω σ = ω ′ O ⊑ P ω O 7→  ω ′ := x P ; σ − → ω O 7→ x  unit ( Reduct execute ) ω σ = ω ′ pack ( f ) ∈ σ ( x ) P ′ = P ⊓ O ω O 7→ x  exec ω ′ P ; σ − → ω O 7→ x  [ P ′ ] f ( Reduct un/protect ) ω σ = ω ′ O ⊔ O ′ ⊑ P ω O 7→ x  h O ′ i ω ′ P ; σ − → ω O ′ 7→ x  unit Structural equivalence a ≡ b ( Struct bind ) E P ; σ J a { x/y } K P ′ ,σ ′ ≡ E P ; σ J ( ν x/y @ P ′ ) a K P ′ ,σ ′ ( Struct substituti on ) x / ∈ fv ( E P ,σ ) ∪ bv ( E P ,σ ) fv ( µ ) ∩ bv ( E P ,σ ) = ∅ E P ; σ J ( ν x/µ @ P ′′ ) a K P ′ ,σ ′ ≡ ( ν x/µ @ P ′′ ) E P , { x/µ @ P ′′ }∪ σ J a K P ′ ,σ ′ ( Struct for k ) fv ( a ) ∩ bv ( E P ,σ ) = ∅ E P ; σ J a  b K P ,σ ′ ≡ a  E P ; σ J b K P ,σ ′ ( Struct store ) [ P ] ( ω O 7→ x  a ) ≡ ω O 7→ x  [ P ] a ( Struct equiv ) ≡ is an e quiv alence Global reduction a P ; σ − → b p ( Reduct context ) a P ′ ; σ ′ − → b E P ; σ J a K P ′ ; σ ′ P ; σ − → E P ; σ J b K P ′ ; σ ′ ( Reduct congruence ) a ≡ a ′ a ′ P ; σ − → b ′ b ′ ≡ b a P ; σ − → b rewriting the process q 2 as ( ν x/ empty @ Low ) [ High ] ( · · ·  home := x )  . . . DFI pre vents this particular instance ( x ) of empty from being written to home ; but it allows other instances whose sources are at least as trusted as Medium . T he rewriting follows a structural equi valence rule ( Struct bind ), explained later in the section. While explicit substitution has been pre viously used in language implementations, we seem to be the ﬁrst to adapt this de vice to track data ﬂow in a concurrent language. In particular , we use explicit substitution both to specify DFI (in Deﬁ nitions 3.3 and 3.4) and to verify it statically ( in proofs of Theorems 5.4 and 5.7). W e defer a more detailed discussion on this technique to Section 6. W e call sets of the form { x 1 /µ 1 @ P 1 , . . . , x k /µ k @ P k } substi- tution en vir onments . Deﬁnition 3.3 (E xplicit ﬂ o ws) . A variable x ﬂows fr om a label P or l ower in a substitution en vironmen t σ , written x σ H P , if x/µ @ P ′ ∈ σ for some µ and P ′ such that either P ′ ⊑ P , or µ is a variable and (inductively) µ σ H P . In other words, x ﬂows from a label P or lo wer if x is an instance of a value substituted at P or lower . In Deﬁnition 3.4 belo w , we formalize DFI as a property of objects, as foll o ws: an object is protec t ed fr om label L if i t never contains instances that ﬂow from L or lower . W e deﬁne σ ( x ) to be the set of valu es in σ that x is an instance of: x ∈ σ ( x ) , and if (inducti vely) y ∈ σ ( x ) and y /u @ ∈ σ for some y and u , then u ∈ σ ( x ) . The operational semantics ensures that substitution en vironments accurately associate instances o f v alues w ith their run t ime sources. W e no w present rules for loc al redu ction, structural equiv alence, and global reduction. Reductions are of t he form a P ; σ − → b , mean- ing t hat “process a may reduce to process b with label P in sub- stitution en vironment σ ”. St ructural equiv alences are of the form a ≡ b , meaning that “process a may be rewritten as process b ”. The notions of free and bound va r iables ( fv and bv ) are standard. W e write x σ = y if σ ( x ) ∩ σ ( y ) 6 = ∅ , that i s, t here is a value that both x and y are instances of. W e ﬁ rst look at the local reduction rules. In ( Reduct e valuate ), a substitution binds x to the i ntermediate value u and associates x with it s runtime source P . ( Reduct new ) creates a new st ore denoted by a fresh variable ω , initializes the store, and returns ω ; a substitution binds ω to the i nitialization of the ne w object and associates ω with its runtime source P . T he v alue x and the trust annotation S in t he initialization are used by the type system (Section 4). The remaining local reduction rules describe reactions with a store, follo w ing the informal semantics. Next, we deﬁne e valuation contex t s [20]. An e v aluation context is of the form E P ; σ , and contains a hole of the form • P ′ ; σ ′ ; the contex t yields a process that execu t es with label P in substitution en vironment σ , if the hole is plugged by a process that executes with label P ′ in substitution en vironment σ ′ . E P ; σ ::= ev aluation context • P ; σ hole let x = E P ; σ in b sequential ev aluation E P ; σ  b fork left a  E P ; σ fork right ( ν x/µ @ P ′ ) E P ; { x/µ @ P ′ }∪ σ explicit substitution [ P ′ ] E P ′ ; σ ( P ′ ⊑ P ) lo w ering of process label Eva l uation can proceed sequentially inside let processes, and in parallel under forks [24]; it can also proceed under explicit sub- stitutions and lowering of process labels. In particular , note ho w e valuation contexts build substitution en vironments from explicit substitutions, and labels fr om changes of process labels. W e denote by E P ; σ J a K P ′ ; σ ′ the process o btained by plugging the hole • P ′ ; σ ′ in E P ; σ with a . Next, we look at the structural equ iv alence and g lobal reduction rules. In ( S truct b ind ), a { x/y } i s the process obtained from a by the usual capture-av oiding substitution of x by y . The rule states that explicit substitution may in vert usual substitution to create instances as required. In particular , variables that appear in packe d code can be associated with the label of the process that packs that code, e ven though those variables may be bound later— by ( Reduct ev aluate )—when that code is ev entually unpacke d at some other labe l . Fo r example, the instance of empt y in binVirus may be correctly associated with Low (the label at which it is packe d) instead of High (the label at which it is unpacked ) . Thus, in combination, the rules ( Reduct ev aluate ) and ( Struct bi nd ) track precise sources of v alues by exp l icit substitution. By ( Struct su bstitution ), substitutions can ﬂoat ac ross c ontexts under standard scoping restrictions. By ( Struct fork ), forked pro- cesses can ﬂoat across contex ts [24], but must remain under the same process label. By ( Struct store ), st ores can be shared across further contex t s. Reduction is extended wit h contexts and structural equiv alence in the natural way . Finally , we formalize DFI in our langua ge, as promised. Deﬁnition 3.4 (DFI) . The object ω is pr otected fr om label L by pr ocess a i f ther e is no proce ss b , substitution envir onment σ , and instance x such tha t a  [ L ] b ⊤ , ∅ − → ⋆ E ⊤ , ∅ J ω 7→ x K ⊤ ,σ and x σ H L . 4. A type system to enf o rce DFI W e no w sho w a type system to enforce DFI in t he language. (The formal protection guarantee for well-typed code appears in Sec- tion 5 .) W e begin by introducing types and typing judgments. W e then present typing rules and informally explain their properties. Finally , w e consider some exam ples of typechecking. An efﬁcient algorithm for typecheckin g is outlined in Appendix B. 4.1 T ypes and effects The co re grammar of types is shown b elo w . Here effects are simply labels; t hese labels belong to the same ordering ⊑ as i n the opera- tional semantics. τ ::= type Ob j ( T ) object ∇ P . Bin ( T ) packe d code Unit unit T ::= s t atic approximation τ E type and effec t • The type Ob j ( τ S ) is giv en to an object that contains values of type τ . Such contents may not ﬂow from lab els lowe r than S ; in other words, S indicates the t rust on the contents of t his object. DFI follo ws f rom the soundn ess of object types. • The type ∇ P . Bin ( τ E ) is given to packe d code t hat can be r un with label P . V alues returned by the code must be of type τ and may not ﬂo w from labels lower than E . In fact, our type sy stem admits a subtyping rule that allows such code t o be run in a typesafe manner with any label that is at most P . • The effect E is giv en to a value that does not ﬂow from l abels lo w er than E . When creating an object, the programmer declares the trust on the contents of that object. Roughly , an object returned by n ew ( # S ) gets a type Ob j ( S ) . For example, in Examples 3.1 and 3.2, we de- clare the tr ust ⊤ on the contents of cmd . exe and the trust Medium on the contents of home . Core typing judgments Γ ⊢ P a : T ( T yp u nit ) Γ ⊢ P unit : Unit P ( T yp variable ) x : τ E ∈ Γ Γ ⊢ P x : τ E ⊓ P ( T yp fork ) Γ ⊢ P a : Γ ⊢ P b : T Γ ⊢ P a  b : T ( T yp li mit ) Γ ⊢ P ′ a : T Γ ⊢ P [ P ′ ] a : T ( T yp evaluate ) Γ ⊢ P a : T ′ Γ , x : T ′ ⊢ P b : T Γ ⊢ P let x = a in b : T ( T yp su bstitute ) Γ ⊢ P ′ µ : T ′ Γ , x : T ′ ⊢ P a : T Γ ⊢ P ( ν x/µ @ P ′ ) a : T ( T yp store ) { ω : Ob j ( τ S ) , x : τ E } ⊆ Γ S ⊑ O ⊓ E Γ ⊢ P ω O 7→ x : P ( T yp n ew ) Γ ⊢ P x : τ E S ⊑ E Γ ⊢ P new ( x # S ) : Ob j ( τ S ) P ( T yp p ack ) Γ ⊢ P ′ f : T  f Γ ⊢ P pack ( f ) : ∇ P ′ . Bin ( T ) P ( T yp u n/protect ) Γ ⊢ P ω : Ob j ( S ) E S ⊑ O Γ ⊢ P h O i ω : Unit P ∗ P ⇒ ∗ E ( T yp write ) Γ ⊢ P ω : Ob j ( τ S ) E Γ ⊢ P x : τ E ′ S ⊑ E ′ Γ ⊢ P ω := x : Unit P ∗ P ⇒ ∗ E ( T yp read ) ω : Ob j ( τ S ) E ∈ Γ Γ ⊢ P ! ω : τ S ⊓ P ∗ ( P ⊓ S ) ⇒ ∗ E ( T yp execute ) ω : Ob j (( ∇ P ′ . Bin ( τ E ′ )) S ) E ∈ Γ P ⊑ P ′ ⊓ S Γ ⊢ P exec ω : τ E ′ ⊓ P ∗ P ⇒ ∗ E A typ i ng en vironment Γ contains typing hy potheses of the fo rm x : T . W e assu me that any va r iable has at most o ne typing hypothe- sis in Γ , and deﬁne dom (Γ) as the set of va r iables that hav e t yping hypotheses in Γ . A typing judgment is of the form Γ ⊢ P a : T , where P is the label of the process a , T is the type and effect of v alues returned by a , and fv ( a ) ⊆ dom (Γ) . 4.2 Core typing rules In the pre vious page, we present typing rules that enforce the core static discipline required for our protection guarantee. Some of these r ules hav e side conditions t hat inv olve a predicate ∗ on labels. These conditions, which are marked i n shaded box es , are ignored in our ﬁrst reading of these rules. (The predicate ∗ is true e verywhere in the absence of a special label ⊥ , introduced later in the section.) O ne of the rules has a condition t hat inv olves a predicate  on expression s; we introduce that predicate in the discussion belo w . The typing rules preserve se veral i n varian t s. (1) Code that runs wi th a label P cannot return values that have effe ct s higher than P . (2) The contents o f an object of type Ob j ( S ) cannot hav e effects lo w er than S . (3) The dynamic label that protects an object of type Ob j ( S ) cannot be lo wer t han S . (4) An object of type Ob j ( S ) cannot be created at a label lower than S . (5) Packed code of type ∇ P . Bin ( ) must remain well-typed when unpack ed at any label lowe r than P . In variant (1) fo l lo ws f rom our interpretation o f effects. T o preserve this in va r iant in ( T yp variable ), for ex ample, t he ef fect of x at P is obtained by lo wering x ’ s effec t in the typing en vironment with P . In ( T yp store ), typechecking is independent of the process label, that is, a store is well-typed if and only if it is so at any process label; recall that by ( Struct store ) stores can ﬂoat across contex t s, and t yping must be preserved by structural equiv alence. Further , ( T yp store ) introduces In variants (2) and (3). Inv ariant (2) follows from our interpretation of static trust annotations. T o preserve this in variant we require In v ariant (3), which ensures t hat access con tr ol pre vents co de running with lab els less trusted than S from writing to objects whose contents are trusted at S . By ( T yp new ), the effect E o f the initi al content of a ne w object cannot be lower than S . Recall that by ( Reduct new ), the ne w object is protected with t he process label P ; since P ⊒ E by Inv ariant (1), we hav e P ⊒ S , so t hat both In v ariants (2) and (3) are preserve d. Con versely , if P ⊏ S then the process does not typecheck; In varian t (4) follows. Let us now look carefully at the other rules relev ant to In vari- ants (2) and (3); these rules—combined with access control—are the crux of enforcing DFI. ( T yp write ) preserves Inv ariant (2), re- stricting t rusted code from writing v alues t o ω that may ﬂow from labels lower than S . (Such code may not be restricted by access control.) Con versely , access control preve nts code with labels lo wer than S from writing to ω , since by I n varian t (3), ω ’ s lab el is at least as t rusted as S . ( T yp un/protect ) preserves Inv ariant (3), allowing ω ’ s label to be either raised or lowered without falling below S . In ( T yp read ), the effect of a v alue read from ω at P is approxi- mated by S —the least trusted label from which ω ’ s contents may ﬂow—an d f urther lo wered with P to preserv e In variant (1). In ( T yp pack ), packing code requires work akin t o proof- carrying code [39]. T ype safety for the code is prov ed and “carried” in it s type ∇ P ′ . Bi n ( T ) , independently of the current process la- bel. Speciﬁcally , it i s prove d that when the packed code is u npacked by a process with label P ′ , the v alue of ex ecuting that code has type and effect T . In Section 5 we show that such a proof i n fact allo ws the packe d code to be unpack ed by any process with label P ⊑ P ′ , and t he t ype and effect of the v alue of executing that code can be related to T (In variant (5)). This inv ariant is key t o decidable and efﬁcien t typechecking (Appendix B). Of course, code may be packed to run only at speciﬁc process labels, by requiring the appropriate label changes. Preserving In variant (5) entails, in particular, preserv i ng Inv ari- ant (4) at all labels P ⊑ P ′ . Since a new expression t hat is not guarded by a change of the process lab el may be run with an y label P , that e xpression must place the least possible trust on the contents of the object it creates. This condition is enforced by predicate  :  n ew ( x # S ) , ∀ P . S ⊑ P  ( f  g ) ,  f ∧  g  ( let x = f in g ) ,  f ∧  g  ( . . . ) , true ( T yp execute ) relies on In variant (5); further, it checks that the label at which the code is unpacked ( P ) is at most as trusted as the label at which the code may have been packed (approximated by S ). T his check pre vents pri vilege escalation—code that would perhaps block if run w ith a lower label cannot be packed to run with a higher label. For example, r ecall t hat in Example 3.2 , the code binVir us is packed at Lo w and then copied into setup . ex e . While a High -process can legitimately execute home := empty (so that the code is typed and is not blocke d by access control), it should not run that code by unpackin g binVirus f rom setup . exe . The type system preven t s t his violation. Let setup . exe be of type Ob j (( ∇ . Bin ( )) S ) . Then ( T yp st ore ) requires that S ⊑ L o w , and ( T yp execute ) requires that High ⊑ S ( contradiction). Because we do not maintain an upper bound on the dynamic label of an executable, we cannot rely on t he l o wering of the process label in ( Reduct execute ) to prev ent privile ge escalation. (While it is possible to extend our type system to maintain such upper bounds, such an extension does not let us typecheck any more correct programs than we al ready do.) In Section 5, we sho w that the lo w ering of the process label can in fact be safely eliminated. In ( T yp ev aluate ), typing proceeds sequentially , propagating the type and effec t of the intermediate process to the continuation. ( T yp sub stitution ) is similar, exce pt t hat the substituted valu e is typed under t he process label recorded in the substitution, rather than under the current process label. In ( T yp limit ), the continua- tion is typed under the changed process label. In ( T yp fo rk ), the forked process is typed under the current process label. 4.3 T ypin g rules f or stuck code While the rules abov e rely on access con t rol for soundne ss, they do not exploit runtime protection provided by access control to type- check more programs. For example, the r educed process q 1 in Ex- ample 3.1 cannot yet be typed, although we have ch ecked that D FI is not violated in q 1 . Below we introduce stuck typing to identify processes that prov ably block by access control at runtime. Stuck typing allows us to soundly type more programs by composition. (The general principle that is followed here is that narrowing the set of possible ex ecution paths improves t he precision of t he anal- ysis.) This po w erful technique of combining static typing and dy- namic access co ntrol f or runtime protection is quite close to hybrid typechecking [21]. W e defer a more detailed discussion of this tech- nique to Section 6. W e introdu ce the static approximation Stuck for pro cesses that do not return v alues, but may hav e side effects. T ::= s t atic approx i mation · · · code Stuck typing judgments Γ ⊢ P a : Stuck ( T yp escalate stuck ) P ⊏ P ′ Γ ⊢ P [ P ′ ] a : Stuc k ( T yp write stuck ) ω : Ob j ( S ) E ∈ Γ P ⊏ S Γ ⊢ P ω := x : Stuc k ∗ E ( T yp u n/protect stuck ) ω : Ob j ( S ) E ∈ Γ P ⊏ S ⊔ O Γ ⊢ P h O i ω : Stuck ∗ E ( T yp su bsumption stuck-I ) : Stuc k ∈ Γ Γ ⊢ P a : Stuck ( T yp su bsumption stuck-II ) Γ ⊢ P a : Stuck Γ ⊢ P a : T Stuc k stuc k process W e now present rules for stuck-typing. As before, in our ﬁrst read- ing of these rules w e ignore the side conditions in shaded box es (which in volve the predicate ∗ ). ( T yp write stuck ) i dentiﬁes code that t ries t o write to an object whose static trust annotation S is higher than the current process l abel P . By In variant (3), the la- bel O that protects the object must be at l east as high as S ; thus P ⊏ O and the code must block at runtime due to access control. For exa mple, let cmd . exe be of type Ob j ( ⊤ ) in Example 3.1. By ( T yp write stuck ), the cod e q 1 is well-typed sinc e Low ⊏ ⊤ . ( T yp un/protect stuck ) is similar to ( T yp write stuck ); it further identi- ﬁes code that tries to raise the label of an o bject beyond the current process label. ( T yp escalate stuck ) i dentiﬁes code tha t tries to raise the current process label. A ll such processes block at runtime due to access control. By ( T yp su bsumption stuck-I ), processes that are typed under stuck hypotheses are considered stuck as well. For example, this rule combines with ( T yp ev aluate ) to t riv i ally t ype a continuation b if the intermediate process a is identiﬁed as stuck. Finally , by ( T yp subsumption stuck- II ), stuck processes can hav e any type and effect, sin ce t hey canno t return values. 4.4 T ypin g rules f or un trusted code T yping must guarantee protection in arbitrary env i ronments. S ince the p rotection guarantee is derived v ia a type preserv ation theorem, arbitrary untrusted code needs to be accommodated by t he type system. W e assume that untrusted code runs with a special label ⊥ , introduc ed into the total o rder by assuming ⊥ ⊑ L for all L . W e no w present r ules that allo w arbitrary interpretation of t ypes at ⊥ . By ( T yp subsumption ⊥ -I ), placing the static trust ⊥ on the contents of an object amounts to assuming an y type for those contents as required. By ( T yp subsumption ⊥ -II ), a va l ue t hat has effect ⊥ may be assumed to have any type as required. These rules prov ide the necessary ﬂexibility for typing any untrusted code using the othe r typing rules. On the o t her hand, arbitrary su btyping with objects can i n general be unsound—we no w need to be careful T yping rules for untrusted code ( T yp su bsumption ⊥ -I ) Γ , ω : Ob j ( ⊥ ) E ⊢ P a : T Γ , ω : Ob j ( τ ⊥ ) E ⊢ P a : T ( T yp su bsumption ⊥ -II ) Γ , x : ⊥ ⊢ P a : T Γ , x : τ ⊥ ⊢ P a : T when typing trusted code. For e xample, consider the code ω 2 High 7→ x  ω 1 Low 7→ ω 2  [ High ] let z = ! ω 1 in z := u A High -process reads the name of an object ( ω 2 ) from a Low -object ( ω 1 ), and t hen writes u to that object ( ω 2 ). DF I is violated if ω 2 has type Ob j ( High ) and u ﬂows from Lo w . Unfortunately , it turns out that this code can be typed under process label ⊤ and typing hypotheses ω 2 : Ob j ( τ High 2 ) ⊤ , ω 1 : Ob j ( Ob j ( τ High 2 ) ⊥ ) ⊤ , x : τ High 2 , u : τ Low 1 Speciﬁcally , the intermediate judgm ent z : Ob j ( τ High 2 ) ⊥ , . . . , u : τ Low 1 ⊢ High z := u : can be deri ved by adjusting the type of z in the ty ping env ir onment to Ob j ( τ Low 1 ) with ( T yp sub sumption ⊥ -II ). This source of unsoundness is eliminated i f some of the effects in our typing rules are required to be trusted, that is, to be higher than ⊥ . Accordingly we introduce the predicate ∗ , such t hat for any label L , ∗ L simply means L ⊐ ⊥ . W e now revisit t he typ- ing rules earlier in the section and focus on the side conditions in shaded box es (which in volv e ∗ ). In some of those conditions, we care about trusted effects only if the process label is itself trusted. W it h these conditions, ( T yp write ) pre vents typechecking the of- fending write abov e, since the ef fect of z in the typ ing en vironment is untrusted. 4.5 Compromise The label ⊥ introduced above is an artiﬁcial construct to t olerate a degree of “anarchy” in the type system. W e may want t o specify that a certain label (such as Low ) acts like ⊥ , i .e. , is compr omised . The typing judgment Γ ⊢ P a : T despite C allo ws us to type arbitrary code a running at a compromised label C by assuming that C is the same as ⊥ , i. e. , by extending the total order with C ⊑ ⊥ (so that all labels that are at most as trusted as C collapse to ⊥ ). W e do not consider labels compromised at runtime (as in Gordon and Jef fr ey’ s type system for conditional secrecy [26]); ho weve r we do not anticipate any t echnical difﬁculty in i ncluding runtime compromise in our type system. 4.6 T ypechecki ng examples W e now sho w some examples of typecheckin g. W e begin with t he program p 2 in Example 3.2. Recall that DF I is violated in p 2 . Suppo se t hat we t ry to deri ve the typing judgment · · · ⊢ ⊤ p 2 : despite Lo w This amounts to deri ving · · · ⊢ ⊤ p 2 : by assuming Lo w ⊑ ⊥ . As a ﬁ rst step, we apply ( T yp new ), ( T yp read ), ( T yp write ), ( T yp p ack ), and ( T yp ev aluate ), directed by syntax, until we hav e the follo w ing typing en vironment. Γ = . . . , url : Ob j ( Low ) ⊤ , setup . exe : Ob j ( Low ) ⊤ , binIE : ( ∇ Low . Bin ( Unit )) ⊤ , ie . exe : Ob j (( ∇ Low . Bin ( Unit )) ⊤ ) ⊤ , home : Ob j ( Medium ) ⊤ empty : Unit ⊤ The only complication that may arise is in this step is i n deriving an intermediate judgment . . . , z : Low ⊢ ⊤ ! z : Here, we can apply ( T yp subsu mption ⊥ -II ) to adjust the typing hypothesis of z to Ob j ( ) ⊥ , so that ( T yp read ) may apply . After this step, we need to deri ve a judgment of the form: Γ ⊢ ⊤ [ High ] ( . . . )  [ Medium ] ( . . . )  [ Low ] ( . . . ) No w , we apply ( T yp f ork ). W e ﬁrst check that the code [ Lo w ] ( . . . ) is well-typed. (In fact, untrusted code is always well-typed, as we sho w in Section 5.) The judgment Γ ⊢ Low home := empty : Unit typechecks by ( T yp write stuck ). T hus, by ( T yp pack ) and ( T yp ev aluate ), we add the follo wing hypothesis to the typing env i ron- ment. binVirus : ( ∇ Low . Bin ( Unit )) Low Let T binVi rus = ( ∇ Low . Bi n ( Unit )) Low . Next, by ( T yp new ) and ( T yp ev aluate ), we add the following hypothesis to t he typing en vironment. virus . exe : Ob j ( T binVi rus ) Low Finally , the judgmen t Γ , . . . , virus . exe : Ob j ( T binVi rus ) Low ⊢ Low url := virus . exe can be deriv ed by ( T yp write ), after massaging the typ i ng hypothe- sis for virus . exe to the required Low by ( T yp su bsumption ⊥ -II ). On th e other h and, the process [ H igh ] ( . . . ) does not typecheck; as seen abo ve, an intermediate judgment Γ ⊢ High exec setup . e xe : cannot be deri ved, since ( T yp execute ) does not apply . T o understand this situation further , l et us consider some varia- tions where ( T yp ex ecute ) do es apply . Suppose that the code exec z is forked in a new process whose label is lowered to Lo w . Then p 2 typechecks. In particular , the following judgment can be deri ved b y applying ( T yp execute ). Γ ⊢ High [ Lo w ] exec setup . exe : Fortunately , the erasure of home now blocks by access control at runtime, so DFI is not violated. Next, suppose that the static annotation for setup . exe is High instead of Low , and setup . exe is initialized by a process with label High instead of Low . Then p 2 typechecks. In particular , the type of setup . exe in Γ becomes Ob j ( High ) . W e need to derive an intermediate judgment Γ , . . . , x : ⊢ Low setup . exe := x : Uni t This judgment can be deriv ed by applying ( T yp write stu ck ) in- stead of ( T yp write ). Fortunately , the o verwrite of setup . exe now blocks by access control at runtime, so DFI is not violated. Finally , we sketch ho w typechecking fails f or the violations of DFI described in Section 2.2. ( Write and copy ) Let the type of ω be Ob j ( S ) , where O ⊒ S ⊐ P . Then the write to ω ( O ) does not typecheck, since the value to be written is read from ω ′ ( P ) and thu s has some effec t E such that E ⊑ P , so that E ⊏ S . ( Copy and execute ) Let the type of ω ′ be Ob j ( S ′ ) . If S ′ ⊑ O then the execution of ω ′ ( P ) by q ( P ) does not typecheck, since S ′ ⊏ P . If S ′ ⊐ O then the wri te to ω ′ ( P ) does not typecheck, since the va l ue to be wri tten i s read from ω ( O ) and thus has some ef fect E such that E ⊑ O , so that E ⊏ S ′ . ( Unprotect, write, and pr otect ) Let t he type of ω be Ob j ( S ) , where O ⊒ S ⊐ P . Then t he unprotection of ω ( O ) does not typecheck, since P ⊏ S . ( Copy , protect, a n d execute ) Let the type of ω ′ be Ob j ( S ′ ) , where S ′ ⊑ O . Then the execu ti on of ω ′ ( P ) does not type- check, since S ′ ⊏ P . 5. Properties of typing In this section we show sev eral properties of typing, and prov e that DFI i s preserved by well-typed code under arbitrary untrusted en vironments. All proof details appear in Appendix A. W e begin with the proposition t hat untrusted code can always be accommod ated by the type system. Deﬁnition 5.1 (Adversary) . A C -adver sary is any pro cess of the form [ C ] that does not contain stor es, explicit substitutions, and static trust annotation s that are high er than C . Proposition 5.2 (Adversary completeness) . L et Γ be any typing en vir onment and c be any C -adver sary such that f v ( c ) ⊆ dom (Γ) . Then Γ ⊢ ⊤ c : despite C . Proposition 5.2 provid es a simple way to quantify ov er arbi- trary en vironments. By ( T yp fork ) the compo sit ion of a well-typed process with any such enviro nment remains well -typed, and thus enjoys all the prop ert ies of typing. Next, w e present a monotonicity property of typing that is key to decidable and ef ﬁ cient typecheck i ng (Appendix B). Proposition 5.3 (Monotonicity) . The following infer ence rule is admissible. Γ ⊢ P ′ f : τ E  f P ⊑ P ′ Γ ⊢ P f : τ E ⊓ P This rule formalizes In variant (5), and allows inference of “most general” types for packed code (Appendix B). Further , it implies an intuitive proof principle—code that is prov ed safe to run with higher privile ges remains safe t o run with lower privile ges, and co n- versely , code that is prov ed safe against a more po werful adversary remains safe against a less po werful adversary . The key property of typing is that it is preserved by structural equi valence and reduction. P reserv ation depends delicately on the design of the typing ru l es, relying on the systematic maintenance of typing in variants. W e write Γ ⊢ σ , meaning that “the substitution en vironment σ is consistent wit h the typing en vironment Γ ”, if for all x/u @ P ∈ σ there exists T such that x : T ∈ Γ and Γ ⊢ P u : T . Theorem 5.4 (P reserv ation) . Suppose t hat Γ ⊢ σ and Γ ⊢ P a : . Then • if a ≡ b then Γ ⊢ P b : ; • if a P ; σ − → b then Γ ⊢ P b : . W e now present our formal protection guarantee for well- typed code. W e b egin by streng t hening the deﬁnition o f DFI in Section 3 . In particular , we assume t hat part of the adversary is kno wn an d part of it is unk no wn. This assumption allows the analysis to e xploit any sound typing information that may be obtained from the kno wn pa r t of t he adversary . (As a special case, the adversary may be entirely unkno wn, of course. In t his case, we recover Deﬁniti on 3.4; see belo w .) Let Ω be the set of objects that require protection from labels L or lo wer . W e let the unkno wn part of the adversary ex ecute with some process l abel C ( ⊑ L ). W e say that Ω is protected if no such adversary can wr ite any instance that ﬂows from L or lower , to any ob j ect in Ω . Deﬁnition 5.5 (Strong DFI) . A set of objects Ω is protec t ed by code a from label L despite C ( ⊑ L ) if there is no ω ∈ Ω , C - adver sary c , substitution en vironme nt σ , and instance x such that a  c ⊤ , ∅ − → ⋆ E ⊤ , ∅ J ω 7→ x K ⊤ ,σ and x σ H L . For examp l e, we may want to prove that some code protects a set of High -objects from Medium despite (the compromised label) Lo w ; then we need to show that no instance may ﬂow from Medium or lowe r to any of those Hi gh -objects under any Lo w -adversa r y . W e pick objects that req uire protection based on their types and effe ct s in the typing en vironment. Deﬁnition 5.6 (Trusted o bjects) . The set of objects whose contents ar e trusted be yond the l abel L in the typing env i r onment Γ is { ω | ω : Ob j ( S ) E ∈ Γ and S ⊓ E ⊐ L } . Suppose that in some typing en vironment, Ω is the set of ob- jects whose contents are trusted beyo nd l abel L , and C ( ⊑ L ) i s compromised; we guarantee that Ω is protected by any well -typed code from L despite C . Theorem 5.7 (Enforcement of strong DFI) . Let Ω be the set of objects whose contents ar e trusted be yond L in Γ . Suppos e t hat Γ ⊢ ⊤ a : despite C , wher e C ⊑ L . Then a pro t ects Ω fr om L despite C . In the sp ecial case where the adv ersary is entirely unkno wn, we simply consider L and C to be the same label. The typ e system further enforces DFI for ne w objects, as can be veriﬁed by applying Theorem 5.4 , ( T yp substitute ), and T heorem 5.7. Finally , the type system suggests a sound runtime optimization: whene ver a wel l-typed process ex ecutes packed code in a trusted contex t , t he current process label is already appropriately lowe red for ex ecution. Theorem 5.8 (Redundanc y of ex ecution control) . Suppose that Γ ⊢ ⊤ a : despite C and a ⊤ ; ∅ − → ⋆ E ⊤ ; ∅ J ω O 7→  exec ω ′ K P ; σ such that ω σ = ω ′ and P ⊐ C . T hen P ⊑ O . It follows that the rule ( Reduct execute ) can be safely opti- mized as follo ws. ω σ = ω ′ pack ( f ) ∈ σ ( x ) ω O 7→ x  exec ω ′ P ; σ − → ω O 7→ x  f This optimization should not be surprising. Lowering the process label for execution aims to prev ent trusted code from ex ecuting untrusted code in trusted contexts; our core static discipline on trusted code ef fectiv ely subsumes t his runtime control. On the other hand, write-access control cannot be eliminated by any discipline on trusted code, since that control is required to restrict untrusted code. Lastly , typechecking can be efﬁcien tly mechanized thanks t o Proposition 5.3 and our syntactic restriction on nested packing. A typechecking algorithm is outlined in Appendix B. Theorem 5.9 (T ypechecking) . Given a typing en vi r onment Γ and code a w ith L distinct labe l s, the pr oblem of whethe r there exists T such that Γ ⊢ ⊤ a : T , is decidable in time O ( L | a | ) , wher e | a | is the size of a . 6. Limitations, related w ork , and discussion In this paper we formalize DF I—a multi-leve l i ntegrity property based on explicit ﬂows—and present a type system that can efﬁ- ciently enforce DFI in a language t hat simulates W i ndo ws V ista’ s security en vironment. Not surprisingly , our type system is only a conserv ative tech- nique to enforce DFI—while ev ery program that typecheck s is guaranteed to satisfy DFI (as stated in Theorem 5.7), well-typedness is not necessary for DFI. By design, our analysis is control-insensitiv e—it does not track implicit ﬂows. In many applications, implicit ﬂ o ws are of serious concern. It remains possible to extend our analysis to account for such ﬂows, follo wi ng the ideas of [50, 54, 38, 36]. Howe ver , we belie ve that it is more practical to enforce a weaker property l ike DFI at the lev el of an operating system, and enforce stronger , control-sensiti ve properties like noninterference at the leve l of the application, with speciﬁc assumptions. Our core security calculus is simpliﬁed, although we take care to i nclude all aspects that require conceptua l modeling for r eason- ing about DFI. I n particular , we model threads, mutable references, binaries, and data and code pointers; other features o f x86 binaries, such as recursion, control ﬂ o w , and parameterized procedures, can be encoded in t he core calculus. W e also model all details of Win- do ws V ista that are relev ant for mandatory integrity control with dynamic lab els. On the other hand, we do not mod el details such as discretionary access control, ﬁle virtualization, and secure autho- rization of privileg e escalation [31], which can improv e the preci- sion of our analysis. Building a t ypecheck er that works at t he le vel of x86 binaries and handles all details of Windo ws V ista requires more work. At the same time, we believ e that our analysis can be applied to more concrete programming models by translation. Our work is cl osely related to that of Tse and Zdance wic [48] and Zheng and Myers [59] on noninterference in lambda calculi with dynamic security lev els. While Tse and Z dance wic do not consider mutable references i n their language, i t is possible t o encode the sequential fragment of our calculus in the language of Zheng and Myers; howe ver , well-typed programs i n that fragment that rely on access control for DFI do not remain well-typed via such an encoding. Speciﬁcally , an y restrictive access check for integrity in the presence of dynamically changing labels seems to let the adve r sary i nﬂuence trusted computations in t heir system, violating noninterference [58]. Noninterference is kno wn to be problema t ic for concurrent lan- guages. In this context, Zdance wic and Myers study the notion of observ ational determinism [56 ]; Abadi, Hennessy and Riely , and others study information ﬂow using testing equi valence [1, 28]; and Boudol and Castellani, Honda and Y oshid a, and others u se stronger notions based on observ at ional equiv alence [10, 29]. S ophisticated techniques that in volve linearity , r ace analysis, beha vior types, and liv eness analysis also appe ar in the literature [29, 56, 28, 32]. While most of these t echniques are de veloped in the setting of t he pi cal- culus, other w orks consider distributed and higher -order settings to study mobile code [27, 53, 45] (as in this work). DFI being a safety property [7] gets around some of the dif- ﬁculties posed by noninterference. A related approach guides the design of the opera t ing systems Asbestos [19] and HiStar [57], and dates back to the Clark-W ilson appro ach to security in commercial computer systems [15, 46]. I n comparison with generic models of trace-based integrity that appear in protocol analysis, such as cor- responden ce assertions [25, 22], our integrity model is far more specialized; as a conseq uence, our type system requires fa r less an- notations than ty pe systems for pro ving correspondence assertions. Our deﬁnition of DFI reli es on an operational semantics based on explicit substitution. Explicit substitution, as introduced by Abadi et al. [4], h as been primarily applied to study the co rrectness of abstract machines for programming language s (whose seman t ics rely on substitution as a rather inefﬁcient meta-operation), and in proof en vironments. It also ap pears in the applied pi ca l culus [5] to facilitate an elegan t f ormulation of indistinguisha bil ity for security analysis. Howe ver , we seem to be the ﬁrst to use explicit substitu- tions to track explicit ﬂows i n a concurrent language. Previously , dependen cy analysis [35, 6] has been applied to information-ﬂo w analysis [2, 41, 55]. These analyses track stronger dependen cies than those induced by explicit ﬂows; in particular , the depende n- cies are sensitive t o control ﬂows. In contrast, the use of explicit substitutions to track explicit ﬂows seems rather obviou s and ap- propriate in hindsight. W e believ e t hat this technique should be useful in other conte xts as well. Our analysis manifests a genuine interplay between static typ- ing and d ynamic access control for runtime protec t ion. W e seem to be the ﬁrst to study this interaction in a conc urrent system with dy- namic labels for multi-l e vel integrity . T his approach of combining static and dynamic protection mechanisms is reﬂected in pre vious work, e.g. , on typing for noninterference in a Java - like language with stack inspection and other extensions [8, 40 ], for noninter- ference in l ambda calculi with runtime principals and dynamic la- bels [48, 59 ], and for secrecy i n concurrent storage calculi with discretionary access control mechanisms [14, 13]. A veriﬁcation technique based on this approach is dev eloped by Flanagan [ 21] for a lambda ca l culus with arbitr ary base reﬁnement typ es. In these studies and ours, dynamic checks compleme nt static analysis where possible or as required, so that safety violations that are not caught statically are always caught at runtime. Moreov er, stati c typing sometimes subsumes certain dynamic checks (as in our analysis), suggesting sou nd runtime optimizations. This app r oach is reﬂected in pre vious work on static access control [28, 42, 30]. In most real-world systems, striking t he right balance between security and practice is a delicate task that is nev er far from con- trov ersy . It is reassuring to discove r that perhaps, such a balance can be enforced formally i n a contemporary operating system, and possibly improv ed i n future ones. Acknowledgments W e wish to thank Mart ´ ın Abadi, Ste ve Zdan- ce wi c, Pavol ˇ Cern ´ y, and se veral anonymou s revie wers for their comments on an earlier draft of this paper . W e also wish to thank Karthik Bhar gava n, Cormac Flanagan, and Lantian Zheng for v ari- ous discussions on this work. A vik Chaudhuri’ s work was supported by Microsoft Research India and the National Science Foundation under Grants CCR- 020880 0 and C CF-0524078 . References [1] M. Abadi. Secrecy by typing in security protocols. J ournal of the ACM , 46(5):749–786, 1999. [2] M. Abadi, A. Ba nerjee, N. Hei ntze, and J. G. Rieck e. A core ca lculus of depende ncy . In P OPL’99 : Principles of Pro gramming Language s , pages 147–16 0. ACM, 1999. [3] M. Abadi a nd B. Blan chet. Analyzi ng security prot ocols with secrec y types and logic programs. In POPL’02: Principles of Pr ogramming Languag es , pages 33–44. A CM, 2002. [4] M. Abadi, L. Cardel li, P .-L. Curien , and J.-J. L ´ evy . Explicit substitut ions. In POPL’90: Principles of Pr ogramming Langua ges , pages 31–46. A CM, 1990. [5] M. Abadi and C. Fournet. Mobile value s , new names, and secure communicat ion. In POPL’01 : Principles of Pr ogramming Languages , pages 104–11 5. ACM, 2001. [6] M. Abadi, B. Lampson, and J.-J. L ´ evy . Analysis and caching of depende ncies. In ICFP’96: Functional Pro gramming , pages 83–91. A CM, 1996. [7] B. Alpern and F . B. Schneider . Deﬁning li veness. Information Pr ocessing Letters , 21(5):181–185 , 1985. [8] A. Banerjee and D. Naumann. Using access control for secure informati on ﬂow in a Jav a-like languag e. In CSFW’03: Computer Securit y F oundations W orkshop , pages 155–169. IEEE , 2003 . [9] K. J. Biba. Integri ty considerati ons for secure computer systems. T echni cal Report TR-3153, MITRE Corpora tion, 1977. [10] G. B oudol and I. C astellani. Noninter ference for conc urrent programs and thread s ystems. Theore tical Computer Scienc e , 281(1-2):109– 130, 2002. [11] L. Ca rdelli, G. Ghell i, and A. D. Gordon. Secrecy and group cre ation. Informatio n and Computation , 196(2):127– 155, 2005. [12] M. Castro, M. Costa, and T . Harris. Securing software by enforcing data-ﬂo w integrit y . In OSDI’06: Operati ng Systems Design and Implement ation , pages 147–160. USENIX, 2006. [13] A. Chaudhuri. Dynamic access control in a concurrent object calcu lus. In CONCUR’06: Concurr ency Theory , pages 263–278. Springer , 2006. [14] A. Chaudhuri and M. Abadi. Secrecy by typing and ﬁle-access control . In CSFW’06: Computer Securit y F oundations W orkshop , pages 112–123. IEEE, 2006. [15] D. D. Clark and D. R. W ilson. A comparison of commercial and militar y computer security policie s . In S P ’87: Symposium on Sec urity and Privacy , pages 184–194. IEEE, 1987. [16] J. C lause, W . Li, and A. Orso. Dytan: a generi c dynamic taint analysi s frame work. In ISSTA ’07: Internation al Symposium on Softwar e T esting and Analysis , pages 196–206. A CM, 2007. [17] M. Cono ver . Analysis of the windo ws vista sec urity model . A v ailable at www.symantec.com/avcenter/reference/Windows_ Vista_Security_Model_Analysis.pdf . [18] D. E. De nning and P . J. Denning . Certiﬁcat ion of programs for secure informati on ﬂow . Communicat ions of th e ACM , 20(7 ):504–513, 1977. [19] P . E fstatho poulos, M. K rohn, S. V anDeBogart, C. Frey , D. Ziegler , E. K ohler , D. Mazi ` eres, F . Ka ashoek, and R. Morris. Labels a nd e vent processes in the Asbesto s operati ng system. In SOSP’05: Symposium on Operat ing Systems Principles , pages 17–30. AC M, 2005. [20] M. Felleisen. The theory and practice of ﬁrst-class prompts. In POPL’88: Principles of Pr ogr amming Languages , pages 180–190. A CM, 1988. [21] C. Flanagan. Hybri d type checking. In P OPL’06 : Principles of Pr ogramming Languag es , pages 245–256. A CM, 2006. [22] C. Fournet, A. D . Gordon, and S. Maf feis. A type discipline for authori zation policies. In ESOP’05: Euro pean Symposium on Pr ogramming , pages 141–156. Springer , 2005. [23] J. A. Gogue n and J. Mese guer . Security poli cies and security models. In SP’82: Symposium on Security and P rivacy , pages 11–20. IEEE, 1982. [24] A. D. Gordon and P . D. Hankin. A concurrent object calcu lus: Reduct ion and typing. In HLCL’98: High-Level Concurr ent Languag es , pages 248–264. Elsevi er, 1998. [25] A. D. Gordon and A. J ef frey . T yping corresponde nce assertion s for communicat ion protocols. Theoret ical Computer Science , 300(1- 3):379–409 , 2003. [26] A. D. Gordon and A. Jef frey . Secrecy despite compromise: T ypes, cryptogra phy , and the pi-calculus. In CONCUR’05: Concurrenc y Theory , pages 186–201. Springer , 2005. [27] M. Hennessy , J. Rathke, and N. Y oshida. SafeDpi: A language for control ling mobile code. A cta Informatic a , 42(4-5):227 –290, 2005. [28] M. Hennessy and J. Riely . Information ﬂow vs. resource access in the asynchronous pi-calculu s . ACM T ransact ions on Pr ogramming Languag es and Systems , 24(5):566–591, 2002. [29] K. Honda and N. Y oshida. A uniform type structure for secure infor - mation ﬂow . In POPL’02: P rincipl es of Pr ogramming Language s , pages 81–92. A CM, 2002. [30] D. Hoshina , E. Sumii, and A. Y oneza wa. A typed process cal culus for ﬁne-grain ed resource access control in distribute d computation. In T ACS’01: Theoreti cal Aspects of Computer Software , pages 64–81. Springer , 2001. [31] M. Ho ward and D. LeBla nc. Writing Secur e Code for W indows V ista . Microsoft Press, 2007. [32] N. Kobayashi . T ype-base d information ﬂow analysis for the pi- calcu lus. A cta Informat ica , 42(4-5):291–347, 2005. [33] L. Lamport. Proving the corre ctness of multipro cess programs. IEEE T ransacti ons on Softwar e Engineering , 3(2):125–1 43, 1977. [34] B. W . Lampson. Protect ion. ACM Operating Systems R ev iew , 8(1):18–24 , Jan 1974. [35] J.-J. L ´ evy . R ´ eductio ns corre ctes et optimale s dans le lambda-calcul . PhD thesi s , Univ ersit ´ e Paris 7, 1978. [36] P . Li and S. Zdance wic. Downgradi ng polici es and relaxe d noninter - ference . In POPL’05: Princi ples of Pro gramming Langua ges , pages 158–170. A CM, 2005. [37] L.W all, T .Christiansen, and R.Schw artz. Pr ogramming P erl . O’Reil ly , 1996. [38] A. Myers, A. Sabelfel d, and S. Zdance wic. Enforcing robust decla s siﬁcati on. In CSFW’04: Computer Security F oundation s W orkshop , pages 172–186. IEEE, 2004. [39] G. C. Necula. Proof-carrying code. In P OPL’97: Principles of Pr ogramming Langua ges , pages 106–11 9. ACM, 1997. [40] M. Pistoia , A. Banerje e, and D. A. Naumann. Be yond stack inspect ion: A uniﬁed access-cont rol and informati on-ﬂow security model. In SP ’07: Symposium on Security and Privacy , pages 149– 163. IEEE, 2007. [41] F . Pottier and S. Conchon. Information ﬂow inference for free. In ICFP’00: Functi onal Pro gramming , pages 46–57. AC M, 2000. [42] F . Pottie r, C. Skalka, and S. Smith. A systematic approach to static access control. ACM T ransactions on Pr ogramming Langua ges and Systems , 27(2):34 4–382, 2005. [43] M. Russino vich. Inside W indows V ista User A ccess Contr ol . Microsoft T echnet Magazine , June 2007. A v ailable at http :// www.microsoft.com/technet/technetmag/issues/ 2007/06/UAC/ . [44] A. Sabelfel d and A. Myers. L anguage -based informat ion-ﬂow security . IEEE Journal on Selected Areas in Communica tions , 21(1), 2003. [45] D. Sangior gi, N. Kobayashi , and E. Sumii. E n vironmental bisimu- latio ns for higher-orde r languag es. In LICS’07: Logic in Computer Scienc e , pages 293–302. IEEE , 2007 . [46] U. Shankar , T . Jaeger , and R. Sailer . T ow ard automate d informatio n- ﬂo w inte grity veriﬁcat ion for security-crit ical applicat ions. In NDSS’06: Network and Distributed System Security Symposium . ISOC, 2006. [47] G. E. Suh, J . W . Lee, D. Zhang, and S. Dev adas. Secure program ex ecution via dynamic informatio n ﬂo w trackin g. In ASPLOS’04: Arc hitectur al Support for Pr ogramming Languag es and Operating Systems , pages 85–96. A CM, 2004. [48] S. Tse and S. Zdance wic. Run-ti m e principals in informatio n-ﬂow type s ystems. In SP’04: Symposium on Security and P rivacy , pages 179–193. IEEE, 2004. [49] P . V ogt, F . Nentwich, N. Jov anovic , C. Kruegel, E. Kirda, and G. V igna. Cross s ite scripting pre vention with dynamic data tainting and static analysis. In NDSS’07: Network and Distrib uted System Securit y Symposium . ISOC, 2007. [50] D. V olpa no, C. Irvine, and G. Smith. A s ound type system for secure ﬂo w analysis. J ournal of Computer Securit y , 4(2-3):167–187, 1996. [51] P . W adler and R. B. Findler . W ell-typed programs can’t be blamed. In Scheme ’07: W orkshop on Sche me and Functional Pro gramming , 2007. [52] H. Y in, D. Song, M. Egele, C. Kruege l, and E . Kirda. Panor ama: capturi ng system-wide information ﬂow for malw are detect ion and analysi s . In CCS’07: Computer and Communi cations Security , pages 116–127. A CM, 2007. [53] N. Y oshida. Channel depende nt types for higher -order mobile processes. In POP L ’04: P rincipl es of Pr ogramming Languag es , pages 147–160. A CM, 2004. [54] S. Zda ncewic a nd A. C. Myers. Robust decl assiﬁcation. In CS F W’01: Computer Security F oundations W orkshop , pages 5–16. IE EE, 2001. [55] S. Zdance wic and A. C. Myers. Secure information ﬂow via linea r continuatio ns. Higher Order and Symbolic Computation , 15(2/3):2 09–234, 2002. [56] S. Z dance wic and A. C. Myers. Observ ational determini sm for concurre nt program security . In CSFW’03: Computer Security F oundations W orkshop , pages 29–43. IEEE , 2003 . [57] N. Ze ldovich, S. Boyd-W ickiz er, E. K ohler , and D. Maz i ` eres. Making informati on ﬂow explicit in HiStar . In OSDI’06: Operating Systems Design and Implement ation , pages 19–19. USENIX, 2006. [58] L. Zheng. Personal communication , July 2007. [59] L. Zheng a nd A. Myers. Dynamic security labels and noninterfer ence. In F AST’04: F ormal Aspects in Security and T rust , pages 27–40. Springer , 2004. Appendix In this appendix, we provide some additional material that may beneﬁt the r eader . Fi rst, we detail proofs of our results on typing (Appendix A). Next, we outline an efﬁcient typechecking algorithm (Appendix B). A. Proofs In this section we outline proofs of the results in Section 5. Restatement of Proposition 5.2 (Adversary completeness) Let Γ be any typing en viro nment and e be any C -adversary such t hat fv ( e ) ⊆ dom (Γ) . Then Γ ⊢ ⊤ e : despite C . Pr oof. W e prove typability by i nduction on the structure of pro- cesses. • e ≡ x where u is a v ariable. Then x ∈ dom (Γ) . By ( T yp value ) Γ ⊢ C x : . • e ≡ new ( x # S ) . By I.H. Γ ⊢ C x : τ E Then S ⊑ C ⊑ ⊥ ⊑ E . By ( T yp new ) Γ ⊢ C new ( x # S ) : . • e ≡ h O i ω . By I.H. Γ ⊢ C ω : . So by ( T yp value ) ω : τ E ∈ Γ . Case ∗ E and τ is not of t he form Ob j ( ) . By ( T yp bogus stuck -I ) Γ ⊢ C h O i ω : . Case ∗ E , τ = Ob j ( S ) , and C ⊏ S ⊔ O . By ( T yp un/p rotect stuck ) Γ ⊢ C h O i ω : . Case ∗ E , τ = Ob j ( S ) , and ⊥ ⊑ S ⊔ O ⊑ C = ⊥ . Then S ⊑ O . By ( T yp value ) and ( T yp u n/protect ) Γ ⊢ C h O i ω : . Case E = ⊥ . By ( T yp su bsumption ⊥ -II ) τ = Ob j ( S ) such that S ⊑ O . By ( T yp value ) and ( T yp u n/protect ) Γ ⊢ C h O i ω : . • e ≡ ! ω . By I.H. Γ ⊢ C ω : . So by ( T yp value ) ω : τ E ∈ Γ . Case ∗ E and τ is not of t he form Ob j ( ) . By ( T yp b ogus stuck-I ) Γ ⊢ C ! ω : . Case ∗ E and τ = Ob j ( ) . By ( T yp read ) Γ ⊢ C ! ω : . Case E = ⊥ . By ( T yp su bsumption ⊥ -II ) τ = Ob j ( ) . By ( T yp read ) Γ ⊢ C ! ω : . • e ≡ ω := x . By I.H. Γ ⊢ C ω : and Γ ⊢ C x : τ E ′ 1 . So by ( T yp value ) ω : τ E ∈ Γ . Case ∗ E and τ is not of t he form Ob j ( ) . By ( T yp b ogus stuck-I ) Γ ⊢ C ω := x : . Case ∗ E , τ = Ob j ( S ) , and C ⊏ S . By ( T yp writ e stuck ) Γ ⊢ C ω := x : . Case ∗ E , τ = Ob j ( τ S 1 ) , and ⊥ ⊑ S ⊑ C = ⊥ . Then S ⊑ E ′ . By ( T yp value ) and ( T yp wri te ) Γ ⊢ C ω := x : . Case E = ⊥ . By ( T yp su bsumption ⊥ -II ) τ = Ob j ( τ S 1 ) such t hat S ⊑ E ′ . By ( T yp value ) and ( T yp wri te ) Γ ⊢ C ω := x : . • e ≡ pack ( f ) . By I.H. Γ ⊢ C f : T . By ( T yp p ack ) Γ ⊢ C pack ( f ) : . • e ≡ exec ω . By I.H. Γ ⊢ C ω : , so by ( T yp value ) ω : τ E ∈ Γ . Case ∗ E and τ is not of t he form Ob j ( ) . By ( T yp b ogus stuck-I ) Γ ⊢ C exec ω : . Case τ = Ob j ( τ S 1 ) , ∗ E , and τ 1 is not of the form ∇ . Bin ( ) . By ( T yp b ogus stuck-II ) Γ ⊢ C exec ω : . Case τ = Ob j ( τ S 1 ) , ∗ E , and τ 1 = ∇ P . Bin ( ) . Then C = ⊥ ⊑ P ⊓ S . By ( T yp execute ) Γ ⊢ C exec ω : . Case E = ⊥ . By ( T yp su bsumption ⊥ -II ) τ = Ob j ( τ S 1 ) and τ 1 = ∇ P . Bin ( ) such that C = ⊥ ⊑ P ⊓ S . By ( T yp execute ) Γ ⊢ C exec ω : . Case ∗ E , τ = Ob j ( τ S 1 ) , and S = ⊥ . By ( T yp su bsumption ⊥ -I ) τ 1 = ∇ P . Bin ( ) such t hat C = ⊥ ⊑ P ⊓ S . By ( T yp execute ) Γ ⊢ C exec ω : . • e ≡ [ P ] a . If P ⊐ C then by ( T yp escalate ) Γ ⊢ C [ P ] a : . Otherwise by I.H. Γ ⊢ P a : . By ( T yp limit ) Γ ⊢ C [ P ] a : . • e ≡ let x = a in b . By I.H. Γ ⊢ C a : T and Γ , x : T ⊢ C b : T ′ . By ( T yp evaluate ) Γ ⊢ C let x = a in b : . • e ≡ a  b . By I.H. Γ ⊢ C a : and Γ ⊢ C b : T . By ( T yp fork ) Γ ⊢ C a  b : . ◭ Restatement of Proposition 5.3 (Monotonicity) The following typ- ing rule is admissible. Γ ⊢ P ′ f : τ E  f P ⊏ P ′ Γ ⊢ P f : τ E ⊓ P Pr oof. W e proceed by induction on the structure of deri vations. Suppose that P ′ ⊏ P . Case (T yp variable) x : τ E ∈ Γ Γ ⊢ P x : τ E ⊓ P By ( T yp value ) Γ ⊢ P x : τ E ⊓ P ′ . Here E ⊓ P ′ = E ⊓ P ⊓ P ′ . Case (T yp new) Γ ⊢ P x : τ E S ⊑ E Γ ⊢ P new ( x # S ) : Ob j ( τ S ) P By I.H. Γ ⊢ P ′ x : τ E ⊓ P ′ Then S ⊑ E ⊓ P ′ . By ( T yp new ) Γ ⊢ P ′ new ( x # S ) : Ob j ( τ S ) P ′ . Here P ′ = P ⊓ P ′ . Case (T yp fork) Γ ⊢ P a : Γ ⊢ P b : T Γ ⊢ P a  b : T Let T = τ E . By I.H. Γ ⊢ P ′ a : and Γ ⊢ P ′ b : τ E ⊓ P ′ . By ( T yp fork ) Γ ⊢ P ′ a  b : τ E ⊓ P ′ . Case (T yp store) { ω : Ob j ( τ S ) , x : τ E } ⊆ Γ S ⊑ O ⊓ E Γ ⊢ P ω O 7→ x : P By ( T yp store ) Γ ⊢ P ′ ω O 7→ x : P ′ . Here P ′ = P ⊓ P ′ . Case (T yp un /protect) Γ ⊢ P ω : Ob j ( τ S ) E S ⊑ O Γ ⊢ P h O i ω : Uni t P ∗ P ⇒ ∗ E By I.H. Γ ⊢ P ′ ω : Ob j ( τ S ) E ⊓ P ′ and if ∗ P ′ then ∗ P , then ∗ E , and then ∗ ( E ⊓ P ′ ) . By ( T yp u n/protect ) Γ ⊢ P ′ h O i ω : Uni t P ′ . Case (T yp write) Γ ⊢ P ω : Ob j ( τ S ) E Γ ⊢ P x : τ E ′ S ⊑ E ′ Γ ⊢ P ω := x : Unit P ∗ P ⇒ ∗ E By I.H. Γ ⊢ P ′ ω : Ob j ( τ S ) E ⊓ P ′ and Γ ⊢ P ′ x : τ E ′ ⊓ P ′ and if ∗ L ′ r then ∗ P , then ∗ E , and then ∗ ( E ⊓ P ′ ) and S ⊓ P ′ ⊑ E ′ ⊓ P ′ . If S ⊑ P ′ then S ⊑ E ′ ⊓ P ′ . By ( T yp writ e ) Γ ⊢ P ′ ω := x : Unit P ′ . Otherwise P ′ ⊏ S , so that ∗ S . Because S ⊑ E ′ ⊑ P , we have ∗ P and t hus ∗ E . By ( T yp value ) ω : Ob j ( τ S ) E ′′ ∈ Γ and E ⊑ E ′′ . Then ∗ E ′′ . By ( T yp writ e stuck ) Γ ⊢ P ω := x : Stuc k . By ( T yp subsumption stuck-II ) Γ ⊢ P ω := x : Unit P ′ . Case (T yp execute) ω : Ob j (( ∇ P ′′ . Bin ( τ E ′ )) S ) E ∈ Γ P ⊑ P ′′ ⊓ S Γ ⊢ P exec ω : τ E ′ ⊓ P ∗ P ⇒ ∗ E P ′ ⊏ P ⊑ P ′′ ⊓ S and if ∗ L ′ r then ∗ P , and then ∗ E . By ( T yp execute ) Γ ⊢ P ′ exec ω : τ E ′ ⊓ P ′ . Here E ′ ⊓ P ′ = E ′ ⊓ P ⊓ P ′ . Case (T yp read) ω : Ob j ( τ S ) E ∈ Γ Γ ⊢ P ! ω : τ S ⊓ P ∗ ( S ⊓ P ) ⇒ ∗ E If ∗ ( S ⊓ P ′ ) then ∗ ( S ⊓ P ) , and then ∗ E . By ( T yp read ) Γ ⊢ P ′ ! ω : τ S ⊓ P ′ . Here S ⊓ P ′ = S ⊓ P ⊓ P ′ . Case (T yp limit ) Γ ⊢ P ′′ a : T Γ ⊢ P [ P ′′ ] a : T Let T = τ E . Then E ⊑ P ′′ . If P ′′ ⊑ P ′ then E ⊓ P ′ = E . By ( T yp l imit ) Γ ⊢ P ′ [ P ′′ ] a : τ E ⊓ P ′ . Otherwise P ′ ⊏ P ′′ . By ( T yp escalate stuck ) Γ ⊢ P ′ [ P ′′ ] a : Stuc k . By ( T yp su bsumption stuck-II ) Γ ⊢ P ′ [ P ′′ ] a : τ E ⊓ P ′ . Case (T yp evaluate) Γ ⊢ P a : T ′ Γ , x : T ′ ⊢ P b : T Γ ⊢ P let x = a in b : T Let T = τ E . By I.H. Γ ⊢ P ′ a : T ′′ and Γ , x : T ′′ ⊢ P ′ b : τ E ⊓ P ′ . By ( T yp evaluate ) Γ ⊢ P ′ let x = a in b : τ E ⊓ P ′ . Case (T yp sub stitute) Γ ⊢ P ′ µ : T ′ Γ , x : T ′ ⊢ P a : T Γ ⊢ P ( ν x/µ @ P ′ ) a : T Let T = τ E . By I.H. Γ , x : T ′ ⊢ P ′ a : τ E ⊓ P ′ . By ( T yp substit ute ) Γ ⊢ P ′ ( ν x/µ @ P ′ ) a : τ E ⊓ P ′ . ◭ Lemma A.1 (Bind) . Suppose t hat a = a ′ { x/y } . Then Γ ⊢ P a : if and only if Γ ⊢ P ( ν x/y @ P ) a ′ . Pr oof. By induction on the str ucture of a ′ . ◭ Restatement of Theorem 5.4 (T ype preserv ation) Suppose that Γ ⊢ P σ and Γ ⊢ P a : . Then 1. If a ≡ b then Γ ⊢ P b : . 2. If a P ; σ − → b then Γ ⊢ P b : . Pr oof of (1). W e prov e preserv ation under ≡ by induction on the structure of deri vations. E L ; σ ::= e valuation context • L ; σ hole let x = E L ; σ in b e valuate sequential E L ; σ  b fork child a  E L ; σ fork parent ( ν x/µ @ L ′ ) E L ; { x/µ @ L ′ }∪ σ restrict substitution [ L ′ ] E L ′ ; σ ( L ′ ⊑ L ) lo w er process label Case (Struct substitution ) x / ∈ fv ( E L ; σ ) ∪ bv ( E L ; σ ) fv ( µ ) ∩ bv ( E L ; σ ) = ∅ ( ν x/µ @ L ′′ ) E L , { x/µ @ L ′′ }∪ σ J a K L ′ ; σ ′ ≡ E L ; σ J ( ν x/µ @ L ′′ ) a K L ′ ; σ ′ Let σ ′′ = { x/µ @ L ′′ } ∪ σ . • ( ν x/µ @ L ′′ ) let y = E L ; σ ′′ J a ′ K L ′ ; σ ′ in b ′ ≡ let y = E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ in b ′ and Γ ′ ⊢ L ( ν x/µ @ L ′′ ) let y = E L ; σ ′′ J a ′ K L ′ ; σ ′ in b ′ : T . By ( T yp substit ute ) and ( T yp eva l uate ) Γ ′ ⊢ L ′′ µ : T ′′ and Γ ′ , x : T ′′ ⊢ L E L ; σ ′′ J a ′ K L ′ ; σ ′ : T ′′′ and Γ ′ , x : T ′′ , y : T ′′′ ⊢ L b ′ : T . By ( T yp substit ute ) and S.R. Γ ′ ⊢ L ( ν x/µ @ L ′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′ : T ′′′ and Γ ′ , y : T ′′′ ⊢ L b ′ : T . By I.H. Γ ′ ⊢ L E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T ′′′ . By ( T yp evaluate ) Γ ′ ⊢ L let y = E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ in b ′ : T . • ( ν x/µ @ L ′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′  b ′ ≡ E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′  b ′ and Γ ′ ⊢ L ( ν x/µ @ L ′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′  b ′ : T . By ( T yp substit ute ) and ( T yp fork ) Γ ′ ⊢ L ′′ µ : T ′′ and Γ ′ , x : T ′′ ⊢ L E L ; σ ′′ J a ′ K L ′ ; σ ′ : T ′′′ and Γ ′ , x : T ′′ ⊢ L b ′ : T . By ( T yp substit ute ) and S.R. Γ ′ ⊢ L ( ν x/µ @ L ′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′ : T ′′′ and Γ ′ ⊢ L b ′ : T . By I.H. Γ ′ ⊢ L E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T ′′′ . By ( T yp fork ) Γ ′ ⊢ L E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′  b ′ : T . • ( ν x/µ @ L ′′ ) b ′  E L ; σ ′′ J a ′ K L ′ ; σ ′ ≡ b ′  E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ and Γ ′ ⊢ L ( ν x/µ @ L ′′ ) b ′  E L ; σ ′′ J a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) and ( T yp fork ) Γ ′ ⊢ L ′′ µ : T ′′ and Γ ′ , x : T ′′ ⊢ L E L ; σ ′′ J a ′ K L ′ ; σ ′ : T and Γ ′ , x : T ′′ ⊢ L b ′ : T ′′′ . By ( T yp su bstitute ) and S.R. Γ ′ ⊢ L ( ν x/µ @ L ′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′ : T and Γ ′ ⊢ L b ′ : T ′′′ . By I.H. Γ ′ ⊢ L E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T . By ( T yp fork ) Γ ′ ⊢ L b ′  E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T . • ( ν x/µ @ L ′′ ) ( ν y /µ ′ @ L ′′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′ ≡ ( ν y /µ ′ @ L ′′′ ) E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ and Γ ′ ⊢ L ( ν x/µ @ L ′′ ) ( ν y /µ ′ @ L ′′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) and ( T yp substitu te ) Γ ′ ⊢ L ′′ µ : T ′′ and Γ ′ , x : T ′′ ⊢ L ′′′ v : T ′′′ and Γ ′ , x : T ′′ , y : T ′′′ ⊢ L E L ; σ ′′ J a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) and S.R. Γ ′ , , y : T ′′′ ⊢ L ′′ u : T ′′ and Γ ′ ⊢ L ′′′ µ ′ : T ′′′ and Γ ′ , y : T ′′′ , x : T ′′ ⊢ L E L ; σ ′′ J a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) Γ ′ , y : T ′′′ ⊢ L ( ν x/µ @ L ′′ ) E L ; σ ′′ J a ′ K L ′ ; σ ′ : T . By I.H. Γ ′ , y : T ′′′ ⊢ L E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) Γ ′ ⊢ L ( ν y /µ ′ @ L ′′′ ) E L ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T . • ( ν x/µ @ L ′′ ) [ L ′′′ ] E L ′′′ ; σ ′′ J a ′ K L ′ ; σ ′ ≡ [ L ′′′ ] E L ′′′ ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ and Γ ′ ⊢ L ( ν x/µ @ L ′′ ) [ L ′′′ ] E L ′′′ ; σ ′′ J a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) and ( T yp limit ) Γ ′ ⊢ L ′′ µ : T ′′ and Γ ′ , x : T ′′ ⊢ L ′′′ E L ′′′ ; σ ′′ J a ′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) Γ ′ ⊢ L ′′′ ( ν x/µ @ L ′′ ) E L ′′′ ; σ J a ′ K L ′ ; σ ′ : T . By I.H. Γ ′ ⊢ L ′′′ E L ′′′ ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T . By ( T yp l imit ) Γ ′ ⊢ L [ L ′′′ ] E L ′′′ ; σ J ( ν x/µ @ L ′′ ) a ′ K L ′ ; σ ′ : T . Case (Struct fo rk ) fv ( a ) ∩ bv ( E L ; σ ) = ∅ a  E L ; σ J b K L ≡ E L ; σ J a  b K L • a ′′  let x = E L ; σ J a ′ K L in b ′ ≡ let x = E L ; σ J a ′′  a ′ K L in b ′ and Γ ′ ⊢ L a ′′  let x = E L ; σ J a ′ K L in b ′ : T . By ( T yp fork ) and ( T yp evaluate ) Γ ′ ⊢ L a ′′ : T ′′ and Γ ′ ⊢ L E L ; σ J a ′ K L : T ′′′ and Γ ′ , x : T ′′′ ⊢ L b ′ : T . By ( T yp fork ) Γ ′ ⊢ L a ′′  E L ; σ J a ′ K L : T ′′′ and Γ ′ , x : T ′′′ ⊢ L b ′ : T . By I.H. Γ ′ ⊢ L E L ; σ J a ′′  a ′ K L : T ′′′ . By ( T yp evaluate ) Γ ′ ⊢ L let x = E L ; σ J a ′′  a ′ K L in b ′ : T . • a ′′  E L ; σ J a ′ K L  b ′ ≡ E L ; σ J a ′′  a ′ K L  b ′ and Γ ′ ⊢ L a ′′  E L ; σ J a ′ K L  b ′ : T . By ( T yp fork ) and ( T yp fork ) Γ ′ ⊢ L a ′′ : T ′′ and Γ ′ ⊢ L E L ; σ J a ′ K L : T ′′′ and Γ ′ ⊢ L b ′ : T . By ( T yp fork ) Γ ′ ⊢ L a ′′  E L ; σ J a ′ K L : T ′′′ and Γ ′ ⊢ L b ′ : T . By I.H. Γ ′ ⊢ L E L ; σ J a ′′  a ′ K L : T ′′′ . By ( T yp fork ) Γ ′ ⊢ L E L ; σ J a ′′  a ′ K L  b ′ : T . • a ′′  b ′  E L ; σ J a ′ K L ≡ b ′  E L ; σ J a ′′  a ′ K L and Γ ′ ⊢ L a ′′  b ′  E L ; σ J a ′ K L : T . By ( T yp fork ) and ( T yp fork ) Γ ′ ⊢ L a ′′ : T ′′ and Γ ′ ⊢ L b ′ : T ′′′ and Γ ′ ⊢ L E L ; σ J a ′ K L : T . By ( T yp fork ) Γ ′ ⊢ L b ′ : T ′′′ and Γ ′ ⊢ L a ′′  E L ; σ J a ′ K L : T . By I.H. Γ ′ ⊢ L E L ; σ J a ′′  a ′ K L : T . By ( T yp fork ) Γ ′ ⊢ L b ′  E L ; σ J a ′′  a ′ K L : T . • a ′′  ( ν x/µ @ L ′ ) E L ; σ J a ′ K L ≡ ( ν x/u @ L ′ ) E L ; σ J a ′′  a ′ K L and Γ ′ ⊢ L a ′′  ( ν x/u @ L ′ ) E L ; σ J a ′ K L : T . By ( T yp fork ) and ( T yp substitu te ) Γ ′ ⊢ L a ′′ : T ′′ and Γ ′ ⊢ L ′ ; σ ′ µ : T and Γ ′ , x : T ′′′ ⊢ L E L ; σ J a ′ K L : T . By S.R. Γ ′ , x : T ′′′ ⊢ L a ′′ : T ′′ . By ( T yp fork ) Γ ′ , x : T ′′′ ⊢ L a ′′  E L ; σ J a ′ K L : T . By I.H. Γ ′ , x : T ′′′ ⊢ L E L ; σ J a ′′  a ′ K L : T . By ( T yp substit ute ) Γ ′ ⊢ L ( ν x/u @ L ′ ) E L ; σ J a ′′  a ′ K L : T . Case (Struct store) ω L 7→ u  [ L ′ ] a ≡ [ L ′ ] ( ω L 7→ u  a ) ω L ′′ 7→ u  [ L ′ ] a ′ ≡ [ L ′ ] ( ω L ′′ 7→ u  a ′ ) and Γ ′ ⊢ L ω L ′′ 7→ u  [ L ′ ] a ′ : T . By ( T yp fork ) Γ ′ ⊢ L ω L ′′ 7→ u : and Γ ′ ⊢ L [ L ′ ] a ′ : T . By ( T yp limit ) Γ ′ ⊢ L ′ ω L ′′ 7→ u : and Γ ′ ⊢ L ′ a ′ : T . By ( T yp fork ) Γ ′ ⊢ L ′ ω L ′′ 7→ u  a ′ : T . By ( T yp limit ) Γ ′ ⊢ L [ L ′ ] ω L ′′ 7→ u  a ′ : T . Case (Struct bind) By Lemma A.1. ◭ Pr oof of (2). W e pro ve preserv ati on under − → by induc t ion on the structure of deri vations. Case (Reduct ev aluate) let x = u in a L ; σ − → ( ν x/u @ L ) a Γ ⊢ L let x = u in a ′ : T . By ( T yp evaluate ) Γ ⊢ L u : T ′′ and Γ , x : T ′′ ⊢ L a ′ : T . By ( T yp su bstitute ) Γ ⊢ L ( ν x/u @ L ) a ′ : T . Case (Reduct new) new ( x # S ) P ; σ − → ( ν ω / new ( x # S )@ P ) ( ω P 7→ x  ω ) Γ ⊢ P new ( x # S ) : T . By ( T yp n ew ) Γ ⊢ P x : τ E , S ⊑ E , and T = Ob j ( τ S ) P . By ( T yp store ) Γ , ω : T ⊢ P ω P 7→ x : . By ( T yp fork ) Γ , ω : T ⊢ P ω P 7→ x  ω : T . By ( T yp su bstitute ) Γ ⊢ P ( ν ω / new ( x # S )@ P ) ( ω P 7→ x  ω ) : T . Case (Reduct read) ω σ = ω ′ ω L 7→ x  ! ω ′ L ′ ; σ − → ω L 7→ x  x Γ ⊢ L ω O 7→ x  ! ω ′ : τ E . By ( T yp fork ) Γ ⊢ L ω O 7→ x : . By ( T yp store ) Γ ⊢ L x : . By ( T yp fork ) Γ ⊢ L ω O 7→ x  x : . Case (Reduct write) ω σ = ω ′ L ⊑ L ′ ω L 7→ x  ω ′ := x ′ L ′ ; σ − → ω L 7→ x ′  unit Γ ⊢ L ω O 7→ x  ω ′ := x ′ : Unit L . By ( T yp fork ) Γ ⊢ L ω O 7→ x : and Γ ⊢ L ω ′ := x ′ : Unit L and O ⊑ L . By ( T yp store ), ( T yp write ), and Γ ⊢ σ ω : Ob j ( τ S ) ∈ Γ , S ⊑ O , Γ ⊢ L ω ′ : Ob j ( τ S ) E , Γ ⊢ L x ′ : τ E ′ , and S ⊑ E ′ . By ( T yp store ) Γ ⊢ L ω O 7→ x ′ : . By ( T yp unit ) Γ ⊢ L ω O 7→ unit : Unit L . By ( T yp fork ) Γ ⊢ L ω O 7→ x ′  unit : Uni t L . Case (Reduct execute) ω σ = ω ′ pack ( f ) ∈ σ ( x ) L ′′ = L ′ ⊓ L ω L 7→ x  exec ω ′ L ′ ; σ − → ω L 7→ x  [ L ′′ ] f Γ ⊢ L ω O 7→ x  exec ω ′ : . By ( T yp fork ) Γ ⊢ L ω O 7→ x : and Γ ⊢ L exec ω ′ : . By ( T yp store ), ( T yp execute ), and Γ ⊢ σ Γ ⊢ P ′ pack ( f ) : ∇ P . Bin ( T ) P ′ for some P ′ , x : ∇ P . Bin ( T ) E ∈ Γ , ω : Ob j ( ∇ P . Bin ( T ) S ) ∈ Γ , S ⊑ O ⊓ E , and L ⊑ P ⊓ S . By ( T yp pack ) Γ ⊢ P f : . By ( T yp subsu mption pro cess label ) Γ ⊢ L f : . By ( T yp fork ) Γ ⊢ L ω O 7→ x  f : . Case (Reduct un/protect) ω σ = ω ′ L ⊔ L ′ ⊑ L ′′ ω L 7→ x  h L ′ i ω ′ L ′′ ; σ − → ω L ′ 7→ x  unit Γ ⊢ L ω O 7→ x  h L ′ i ω ′ : Unit L . By ( T yp fork ) Γ ⊢ L ω O 7→ x : and Γ ⊢ L h L ′ i ω ′ : Uni t L O ⊔ L ′ ⊑ L . By ( T yp store ), ( T yp u n/protect ), a nd Γ ⊢ σ , ω : Ob j ( τ S ) ∈ Γ , S ⊑ O , Γ ⊢ L ω ′ : Ob j ( τ S ) , and S ⊑ L ′ . By ( T yp store ) Γ ⊢ L ω L ′ 7→ x : . By ( T yp unit ) Γ ⊢ L unit : Unit L . By ( T yp fork ) Γ ⊢ L ω L ′ 7→ x  unit : Unit L . Case (Reduct context) a L ′ ; σ ′ − → b E L ; σ J a K L ′ ; σ ′ L ; σ − → E L ; σ J b K L ′ ; σ ′ E L ; σ ::= e valuation context • L ; σ hole let x = E L ; σ in b e valuate sequential E L ; σ  b fork child a  E L ; σ fork parent ( ν x/µ @ L ′ ) E L , { x/µ @ L ′ }∪ σ restrict substitution [ L ′ ] E L ′ ; σ ( L ′ ⊑ L ) lo w er process label • let x = E L ; σ J a ′ K L ′ ; σ ′ in b ′ L ; σ − → let x = E L ; σ J a ′′ K L ′ ; σ ′ in b ′ , a ′ L ′ ; σ ′ − → a ′′ , and Γ ⊢ L let x = E L ; σ J a ′ K L ′ ; σ ′ in b ′ : T . By ( Reduct context ) and ( T yp evaluate ) E L ; σ J a ′ K L ′ ; σ ′ L ; σ − → E L [ [ a ′′ ] ] L ′ ; σ ′ , Γ ⊢ L E L ; σ J a ′ K L ′ ; σ ′ : T ′′ , and Γ , x : T ′′ ⊢ L b ′ : T . By I.H. Γ ⊢ L E L ; σ J a ′′ K L ′ ; σ ′ : T ′′ . By ( T yp evaluate ) Γ ⊢ L let x = E L ; σ J a ′′ K L ′ ; σ ′ in b ′ : T . • E L ; σ J a ′ K L ′ ; σ ′  b ′ L ; σ − → E L ; σ J a ′′ K L ′ ; σ ′  b ′ , a ′ L ′ ; σ ′ − → a ′′ , and Γ ⊢ L E L ; σ J a ′ K L ′ ; σ ′  b ′ : T . By ( Reduct context ) and ( T yp fork ) E L ; σ J a ′ K L ′ ; σ ′ L ; σ − → E L ; σ J a ′′ K L ′ ; σ ′ , Γ ⊢ L E L ; σ J a ′ K L ′ ; σ ′ : T ′′ , and Γ ⊢ L b ′ : T . By I.H. Γ ⊢ L E L ; σ J a ′′ K L ′ ; σ ′ : T ′′ . By ( T yp fork ) Γ ⊢ L E L ; σ J a ′′ K L ′ ; σ ′  b ′ : T . • b ′  E L ; σ J a ′ K L ′ ; σ ′ L ; σ − → b ′  E L ; σ J a ′′ K L ′ ; σ ′ , a ′ L ′ ; σ ′ − → a ′′ , and Γ ⊢ L b ′  E L ; σ J a ′ K L ′ ; σ ′ : T . By ( Reduct context ) and ( T yp fork ) E L ; σ J a ′ K L ′ ; σ ′ L ; σ − → E L ; σ J a ′′ K L ′ ; σ ′ , Γ ⊢ L E L ; σ J a ′ K L ′ ; σ ′ : T , and Γ ⊢ L b ′ : T ′′ . By I.H. Γ ⊢ L E L ; σ J a ′′ K L ′ ; σ ′ : T . By ( T yp fork ) Γ ⊢ L b ′  E L ; σ J a ′′ K L ′ ; σ ′ : T . • ( ν x/u @ L ′′ ) E L ; σ J a ′ K L ′ ; σ ′ L ; σ − → ( ν x/u @ L ′′ ) E L ; σ J a ′′ K L ′ ; σ ′ , a ′ L ′ ; σ ′ − → a ′′ , and Γ ⊢ L ( ν x/u @ L ′′ ) E L ; σ J a ′ K L ′ ; σ ′ : T . By ( Reduct context ) and ( T yp sub stitute ) E L [ [ a ′ ] ] L ′ ; σ ′ L ; σ − → E L ; σ J a ′′ K L ′ ; σ ′ , and Γ ⊢ L ′′ u : T ′′ , and Γ , x : T ′′ ⊢ L E L ; σ J a ′ K L ′ ; σ ′ : T . By I.H. Γ , x : T ′′ ⊢ L E L ; σ J a ′′ K L ′ ; σ ′ : T . By ( T yp su bstitute ) Γ ⊢ L ( ν x/u @ L ′′ ) E L ; σ J a ′′ K L ′ ; σ ′ : T . • [ L ′′ ] E L ′′ ; σ J a ′ K L ′ ; σ ′ L ; σ − → [ L ′′ ] E L ′′ ; σ J a ′′ K L ′ ; σ ′ , a ′ L ′ ; σ ′ − → a ′′ , and Γ ⊢ L [ L ′′ ] E L ′′ ; σ J a ′ K L ′ ; σ ′ : T . By ( Reduct context ) and ( T yp limit ) E L ′′ ; σ J a ′ K L ′ ; σ ′ L ′′ ; σ − → E L ′′ ; σ J a ′′ K L ′ ; σ ′ and Γ ⊢ L ′′ E L ′′ ; σ J a ′ K L ′ ; σ ′ : T . By I.H. Γ ⊢ L ′′ E L ′′ ; σ J a ′′ K L ′ ; σ ′ : T . By ( T yp l imit ) Γ ⊢ L [ L ′′ ] E L ′′ ; σ J a ′′ K L ′ ; σ ′ : T . Case (Reduct congruence) a ≡ a ′ a ′ L ; σ − → b ′ b ′ ≡ b a L ; σ − → b Γ ⊢ L a : T , a ≡ a ′ , a ′ L ; σ − → b ′ , and b ′ ≡ b . By Theorem 5.4(1) Γ ⊢ L a ′ : . By I.H. Γ ⊢ L b ′ : . So by Theorem 5.4(1) Γ ⊢ L b : . ◭ Restatement of Theorem 5.7 (Enforcement of strong DFI) Let Ω be the set of objects w hose contents ar e trusted be yond L in Γ . Suppose that Γ ⊢ ⊤ a : despite C , wher e C ⊑ L . Then a pr otects Ω fr om L despite C . Pr oof. Let e be any C -adversary [ C ] e ′ . By Proposition 5.2 Γ ⊢ ⊤ e : . By ( T yp fork ) Γ ⊢ ⊤ a  e : . Suppose that ω ∈ Ω . W e need to prove that t here are no σ and x such that a  [ C ] e ′ ⊤ − → ⋆ E ⊤ ; ∅ J ω 7→ x K ⊤ ; σ and x σ H L . Assume otherwise. By Theorem 5.4 there exists Γ ′ extend i ng Γ such that Γ ′ ⊢ σ and Γ ′ ⊢ ⊤ ω 7→ x : . By ( T yp store ) ω : Ob j ( τ S ) ∈ Γ ′ such that S ⊑ E . W e proceed by induction on the deriv ation of x σ H L . Case P ⊑ L . For some τ and E , Γ ′ ⊢ P µ : τ E . Then E ⊑ P and by ( T yp value ) Γ ′ ⊢ ⊤ x : τ E . Then E ⊑ L . Then S ⊑ L . But by assumptions S ⊐ L ( contradiction). Case µ ≡ y for some y and y σ H L . By I.H. Γ ′ ⊢ ⊤ y : τ E for some E such that E ⊑ L . Then S ⊑ L . But by assumptions S ⊐ L ( contradiction). ◭ Restatement of Theorem 5.8 (Redundanc y of execution control) Suppose that Γ ⊢ ⊤ a : despite C and a ⊤ ; ∅ − → ⋆ E ⊤ ; ∅ J ω O 7→ x  exec ω ′ K P ; σ such that ω σ = ω ′ , and P ⊐ C . Then P ⊑ O . Pr oof. The proof is by inspection of Case (Reduct execute) in the proof of Theorem 5.4. R ecalling that case (where L is the process label): L ⊑ S ⊑ O . ◭ B. An efﬁcient typechec king algor ithm Finally , we outline an efﬁcient algorithm to mechanize typecheck- ing. Broadly , the algorithm builds constraints and then checks whether those constraints are satisﬁable. The only complication is due t o pack processes, which require a “most general” type. W e extend the grammar of types with type va r iables χ , and introduce a distinguished label ? denoting an “unkno wn” label. W e extend the grammar of t yping en vironments with constraints of the form τ 1 < : τ 2 and label constraints ( i.e. , boolean fo rmulae ov er atoms of the form L 1 ⊑ L 2 ). Next, we introd uce the following typechec king judgments: T ypecheckin g judgments f or processes Γ ⊢ P a : T ⊲ Γ ′ ( T ypc value ) x : τ E ∈ Γ Γ ⊢ P x : τ E ⊓ P ⊲ ∅ ( T ypc new ) Γ ⊢ P u : τ E ⊲ ∅ . . . Γ ⊢ P new ( u # S ) : Ob j ( τ S ) P ⊲ ∅ ( T ypc pack ) Γ ⊢ f : T ⊲ Γ ′ Γ ′ | = P ′  f Γ ⊢ P pack ( f ) : χ P ⊲ Γ ′ ? 7→ P ′ , ∇ P ′ . Bin ( T ) < : χ ( T ypc fork ) Γ ⊢ P a : ⊲ Γ 1 Γ ⊢ P b : T ⊲ Γ 2 Γ ⊢ P a  b : T ⊲ Γ 1 , Γ 2 ( T ypc evaluate ) Γ ⊢ P a : T ′ ⊲ Γ 1 Γ , Γ 1 , x : T ′ ⊢ P b : T ⊲ Γ 2 Γ ⊢ P let x = a in b : T ⊲ Γ 1 , Γ 2 ( T ypc read ) ω : Ob j ( τ S ) E ∈ Γ . . . Γ ⊢ P ! ω : τ S ⊓ P ⊲ ∅ ( T ypc write ) Γ ⊢ P ω : Ob j ( τ S 1 ) E Γ ⊢ P u : τ E ′ 2 . . . Γ ⊢ P ω := u : Ob j ( τ S ) E ⊲ τ 2 < : τ 1 ( T ypc execute ) ω : Ob j ( τ S 1 ) E , ∇ P ′ . Bin ( τ E ′ ) < : τ 1 ∈ Γ . . . Γ ⊢ P exec ω : τ E ′ ⊓ P ⊲ τ 1 < : ∇ P . Bin ( τ P ′ ⊓ P ) . . . • Γ ⊢ P a : T ⊲ Γ ′ , where Γ ′ contains constraints of the form τ 1 < : τ 2 only ( i.e. , the label constraint in Γ ′ is true). • Γ ⊢ f : T ⊲ Γ ′ , where Γ ′ may contain a label constraint as well as constraints of the form τ 1 < : τ 2 . W e no w present some sample typechecking rules, followed by ru l es that interpret < : . Let us ﬁrst look at the rules for deriving judgments of the form Γ ⊢ P a : T ⊲ Γ ′ . These rules build constraints of the form τ 1 < : τ 2 in Γ ′ . W e el ide by dots ( . . . ) label constraints that appear in the o r iginal typing rules. Let Γ ′ ? 7→ L denote the typ ing en vironment obtained from Γ ′ by replacing all occurrences of ? with L . W e writ e Γ ′ | = P iff P is the highest L for which the label constraint in Γ ′ ? 7→ L is true. Note t hat to derive a j udgmen t of this form for a process pack ( f ) , we need to deriv e a judgment of the other form f or f . In fact, the two kinds of judgments are mutually recursi ve (see below). Next, we l ook at the rules for deriving judgments of the form Γ ⊢ f : T ⊲ Γ ′ . These rules apply to exp r essions t hat are not explicitly under a change of the process label, e.g. , expressio ns obtained by unpacking pack processes. They build label cons t raints from those that appear in the original typing rules; t he implicit (unkno wn) process label is replaced by ? . P redicate  ensures t hat T ypecheckin g judgments f or expressions Γ ⊢ f : T ⊲ Γ ′ ( T ypc ? value ) x : τ E ∈ Γ Γ ⊢ x : τ E ⊓ ? ⊲ ∅ ( T ypc ? limit ) Γ ? 7→ P ′ ⊢ P ′ a : T ⊲ Γ ′ Γ ⊢ [ P ′ ] a : T ⊲ Γ ′ ( T ypc ? read ) ω : Ob j ( τ S ) E ∈ Γ Γ ⊢ ! ω : τ S ⊓ ? ⊲ . . . ( T ypc ? write ) Γ ⊢ ω : Ob j ( τ S 1 ) E Γ ⊢ u : τ E ′ 2 Γ ⊢ ω := u : Ob j ( τ S ) E ⊲ τ 2 < : τ 1 , . . . ( T ypc ? execute ) ω : Ob j ( τ S 1 ) E , ∇ P ′ . Bin ( τ E ′ ) < : τ 1 ∈ Γ Γ ⊢ exec ω : τ E ′ ⊓ ? ⊲ τ 1 < : ∇ ? . Bin ( τ P ′ ⊓ ? ) , . . . ( T ypc ? fork ) Γ ⊢ a : ⊲ Γ 1 Γ ⊢ b : T ⊲ Γ 2 Γ ⊢ f  g : T ⊲ Γ 1 , Γ 2 ( T ypc ? evaluate ) Γ ⊢ a : T ′ ⊲ Γ 1 Γ , Γ 1 , x : T ′ ⊢ b : T ⊲ Γ 2 Γ ⊢ let x = f in g : T ⊲ Γ 1 , Γ 2 . . . Satisﬁability of constraints Γ ⊢ ⋄ ( T ypc < : obj ) Γ ⊢ ⋄ Γ , Ob j ( T ) < : Ob j ( T ) ⊢ ⋄ ( T ypc < : bin ) P ′ ⊑ P Γ , τ 1 < : τ 2 ⊢ ⋄ Γ , ∇ P . Bin ( τ E 1 ) < : ∇ P ′ . Bin ( τ E ⊓ P ′ 2 ) ⊢ ⋄ ( T ypc < : left ) Γ , χ < : ∇ P . Bin ( τ E 1 ) , ∇ P . Bin ( τ E 1 ) < : ∇ P ′ . Bin ( τ E ′ 2 ) ⊢ ⋄ Γ , χ < : ∇ P . Bin ( τ E 1 ) , χ < : ∇ P ′ . Bin ( τ E ′ 2 ) ⊢ ⋄ ( T ypc < : right ) Γ , ∇ P . Bin ( τ E 1 ) < : ∇ P ′ . Bin ( τ E ′ 2 ) , ∇ P ′ . Bin ( τ E ′ 2 ) < : χ ⊢ ⋄ Γ , ∇ P . Bin ( τ E 1 ) < : χ, ∇ P ′ . Bin ( τ E ′ 2 ) < : χ ⊢ ⋄ ( T ypc < : middle ) Γ , ∇ P . Bin ( τ E 1 ) < : χ, χ < : ∇ P ′ . Bin ( τ E ′ 2 ) , ∇ P . Bin ( τ E 1 ) < : ∇ P ′ . Bin ( τ E ′ 2 ) ⊢ ⋄ Γ , ∇ P . Bin ( τ E 1 ) < : χ, χ < : ∇ P ′ . Bin ( τ E ′ 2 ) ⊢ ⋄ . . . we do not need to consider pa ck processes here; further we can assume that all annotations carry the least trusted label. Once we hav e an expression of the form [ P ] a , we can derive a judgment of the other form for a . Finally , we look at the rules that interpret co nstraints of the form τ 1 < : τ 2 . Here < : denotes a subtyping relation that is in variant i n Ob j ( S ) and cov ariant in ∇ P . Bin ( E ) , and preserv es monotonic- ity . W e introduce the judgment Γ ⊢ ⋄ to che ck satisﬁability of such constraints. W e prov e that typecheck ing is sound and complete. Proposition B.1. The typing judgment Γ ⊢ P a : can be derived if and only if the typechec king judgment Γ ⊢ P a : T ⊲ Γ ′ can be derived for some T and Γ ′ such tha t Γ ′ ⊢ ⋄ . Further , typechecking terminates in t ime O ( L | a | )) if Γ and a hav e L distinct labels. Indeed, let ϕ ( | a | ) be the running time of the judgment Γ ⊢ P a : ⊲ , and ψ ( | f | ) be the total r unning time of the judgments Γ ⊢ f : ⊲ Γ ′ and Γ ′ | = for some Γ ′ . Building constraints for the typechecking judgment Γ ⊢ ⊤ a : T ⊲ Γ ′ takes time ϕ ( | a | ) = O ( | a | + Σ i ∈ 1 ..n ψ ( | f i | )) if a contains as subterms the processes pack ( f 1 ) , . . . , pack ( f n ) without nesting. Checking the satisﬁability of those constraints reduces to detecting cycles in a graph, and takes ti me O ( | a | )) , so the total running time for typechecking is Φ( | a | ) = ϕ ( | a | ) + O ( | a | ) = O ( | a | + Σ i ∈ 1 ..n ψ ( | f i | )) Next, building the label constraint for the typechecking judgment Γ ⊢ f i : T ⊲ Γ ′ takes time O ( | f i | + Σ j ∈ 1 ..m i ϕ ( | a ′ ij | )) if f i contains as subterms the processes [ P i 1 ] a ′ i 1 , . . . , [ P im i ] a ′ im i without nesting. Finding L such that Γ ′ | = L takes time O ( L | f i | )) , since at most O ( L ) labels need to be check ed. So ψ ( | f i | ) = O ( | f i | + Σ j ∈ 1 ..m i ϕ ( | a ij | )) + O ( L | f i | ) = O ( L | f i | + Σ j ∈ 1 ..m i ϕ ( | a ij | )) Plugging the expansion of ψ into the exp ansion of Φ , and solving by induction: Φ( | a | ) = O ( | a | + Σ i ∈ 1 ..n L | f i | + Σ i ∈ 1 ..n,j ∈ 1 ..m i ϕ ( | a ij | )) = O ( L | a | )

A Type System for Data-Flow Integrity on Windows Vista

Original Paper

Comments & Academic Discussion

Leave a Comment

Original Paper

Related Papers

Comments & Academic Discussion

Leave a Comment