Model checking security properties of control flow graphs

Transcription

1 Model checking ecurity propertie of control flow graph Frédéric Beon Thoma Jenen IRIS/CNRS Campu de Beaulieu F Renne Cedex France Tommy Thorn BRICS Univerity of arhu DK-8000 arhu C Denmark 30th September 2005 Daniel Le Métayer Truted Logic 5, rue du Bailliage F Veraille France btract fundamental problem in oftware-baed ecurity i whether local ecurity check inerted into the code are ufficient to implement a global ecurity property. Thi article introduce a formalim baed on a linear-time temporal logic for pecifying global ecurity propertie pertaining to the control flow of the program, and illutrate it expreive power with a number of exiting propertie. We define a minimalitic, ecurity-dedicated program model that only contain procedure call and run-time ecurity check and propoe an automatic method for verifying that an implementation uing local ecurity check atifie a global ecurity property. We then how how to intantiate the framework to the ecurity architecture of Java 2 baed on tack inpection and privileged method call. 1 Introduction number of recently propoed programming language provide language contruct for enforcing ecurity requirement. Example include Telecript [23] with it facilitie for controlling permiion and reource conumption, and the recent verion of Java [12] that provide contruct for granting permiion to code and for checking the permiion of the code executing. Variou feature of thee language have been tudied in a formal etting with the aim of providing emantically well-founded method for verifying that a code i ecure. The connection between type ytem and ecurity have been invetigated by Leroy and Rouaix [20] who proved that well-typing can be ued to guarantee that a program will not corrupt memory. Volpano et al. [35, 36] have devied type ytem for enuring ecure information flow within program. Dean [10], Jenen et al. [16] and Liang and Bracha [21] provide formaliation of the dynamic loading of clae 1

2 in Java. and it influence on protection of code and data. Semantic and verification of bytecode ha been extenively tudied by everal group (ee e.g., [4, 28, 29, 31]). Each of thee contribution focue on one pecific apect of a ecurity architecture. What i till miing, however, i the poibility of proving that a given code i ecure with repect to a global ecurity property (uch a the egregation of duty property [13] for example). The programmer can ue ome of the above-mentioned feature to reduce the viibility of member of clae or to make ecurity check at certain point in the code, but thi doe not guarantee per e that the overall behaviour of the program will be ecure. The tak i complicated by the multitude of facet of ecurity. In Java for example, feature like permiion checking, privileged intruction, viibility modifier for clae and their member, and typing all have an impact on ecurity. It i thu neceary to define a program model that i ufficiently general to accommodate thee feature and yet imple enough to allow the proof of non-trivial propertie. The exiting ecurity model that we are aware of are quite different from the model commonly ued when defining the emantic of high-level programming language uch a Java. Our goal in thi article i preciely to tackle thi problem by howing how a emantic model for modelling control flow can be related to a formalim for pecifying ecurity propertie, thereby providing a tep toward a better integration of abtract pecification of ecurity propertie and implementation uing lower level ecurity mechanim. The contribution of the article i twofold: We provide a formal framework for the definition of a cla of programming language baed ecurity propertie. Thee are propertie that depend only on the control tructure and the control flow graph of the program. We how how thi framework can be intantiated to verify ecurity propertie of application built uing the ecurity architecture of the Java Development Kit (JDK 1.2). We propoe a model checking technique for the verification of thi cla of ecurity propertie. Thi technique take a input the control flow graph and the property to verify and produce a output a finite tate tranition ytem uch that thi finite ytem atifie the property in quetion if and only if the original program atifie the property. The contruction of a control flow graph for a given program involve tatic analyi [2, 14, 25] and will in general only yield a conervative approximation of the real control flow of the program. owever, a tated above, the verification method in itelf i complete. ll verification can be carried out on the finite tate ytem without running the rik of rejecting a control flow graph whoe (poibly infinite) behaviour atifie the given property. Thi i ueful information for the uer to undertand why the verification of a property fail. In that cae the only option for improvement i increaing the preciion of the control flow graph. Thi might then either lead to the verification ucceeding (given that the property hold) or provide control flow information that i ufficiently precie to undertand why the property doe not hold. The abtract model of program with dynamic ecurity check and it operational emantic are introduced in Section 2. In Section 3 we preent a two-level temporal logic for expreing ecurity propertie baed on thi operational emantic. We proceed (Section 4) with the definition of our technique for reducing an infinite tranition 2

3 ytem to a finite and complete one (with repect to a given property). Thi framework i applied to the Java Development Kit (JDK 1.2) in Section 5. In Section 6, we illutrate our model with a mall example inpired by an electronic commerce application. The verification technique i applied to prove that a global ecurity property i enured and to detect redundant dynamic check. Section 7 i devoted to related work and Section 8 ugget avenue for further reearch. 2 Program model In order to define a formal ecurity framework which i not tied to one particular programming language, we introduce in thi ection an abtract model that will erve a the bai for the definition of ecurity propertie in the next ection. The model abtract away all data flow and focue on ecurity check and control flow i.e., which procedure (or method, or function) are called during execution and in what order. program i abtracted by a flow graph with two kind of edge: TG define the tranfer edge (i.e., the uual intra-procedural control flow) and CG the call edge (binding call ite to their potential entry point): So e.g. a code equence uch a m! ();m" () will reult in two node $! and %", repreenting the call m! () and m" (), and a TG-edge from $! to &". In addition there will be a CG-edge from $! to the node() at the beginning of method m! and from %" to the node() at the beginning of method m". See figure 9 in Section 6 for an example of uch a graph. The component of the flow graph have the following ignature: ( ) +-,/ :;.=<>6>.=?@BCD ( ) &E ( ) +GF) ) ( ) +GF) ) C The node (NO) can be een a program point and i the entry point of the whole K program. If JI (repectively JI ) we write ML3N (repectively POCQ ). node can be of the following three kind, a indicated by : n ordinary procedure (or method, or function) call node. check node,.=<>6>.=?@bc, where i a property on the tate of the machine. The.=<63.R? intruction repreent the programming language feature for dynamically enforcing ecurity propertie: execution reaching a check node will top if the current tate doe not atify property. The yntax for defining propertie i preented in the next ection. 3

4 Thi definition of flow graph i liberal and a reaonable tranlation from program to graph would only yield graph that atify ome further well-formedne propertie. In particular, there will be no tranfer edge (S:Q ) coming out of return node and it would be reaonable to eliminate a node from the graph if it i not reachable. Similarly, for call edge TOCQ CU, the ource mut be a call node for the edge to make ene. owever, thee well-formedne propertie are not required for the verification method to be correct and hence are not impoed here. It hould be noted that our minimalitic model doe not contain common control tructure uch a if and while ince thee can be modelled by non-determinim in the flow relation TG. For example, if the call in the tatement m! (); if..then m" () ele mv () are repreented by node! " V then there will be TG-edge from! to " and from W! to &V. For language with dynamic method invocation or higher-order function it i generally not poible to determine tatically what method i invoked in a virtual method call (or function call). The call edge CG decribe for each call node a afe approximation of the poible actual method (or function) that might be invoked by the virtual method call (or function call). The approximation i afe in the ene that if at any point during execution the call at node will reult in control being tranferred to node then there will be an edge XOCQ. owever, there might alo be edge that do not correpond to a call at execution. Such uperfluou edge degrade the preciion of the control flow graph but do not jeopardie the correctne of the verification method that we decribe in the following. For object oriented language uch a Java (that we will conider in Section 5) the technique for contructing the approximate control flow graph are baed on data flow analyi that for each variable determine the clae of thoe object that will be tored in that variable. Thee technique are by now well undertood and their correctne ha been proved (ee e.g., the text book by Palberg and Schwartzbach [26]). The verification technique decribed in thi paper i independent of the particular analyi choen. For now we jut aume that a control flow graph i available and return to the iue of contructing uch a graph when dicuing the application to Java in Section Trace emantic for control flow graph The operational emantic of a flow graph i defined a a tranition ytem with a tate coniting of a control tack. Formally, the tate of the ytem i an element of the et ZY [1\;] ) _^ We ue the variable ` `! à" to range over uch tack. Node model program point in our model, o the control tack i a tack of node. control tack $! &" &V mean that the call at node b! invoked a method during whoe execution node c" wa reached. Node %" in turn repreent a call to a method, mv ay, whoe body contain a node dv which i the current point of control. Thu, the top element of the tack i the current program point of our execution model, indicating which node to execute next. The control tack i ued to determine where 4

5 { { { f D to go to when executing a return node. Referring to the tack above, if bv i a node then execution of the call that wa initiated at node $" ha terminated, and execution continue with the node following W" (cf. the emantic rule for below). The operational emantic of a graph i defined by a tranition relation e. Two tack `! and ` " are related by e, written `! ek` ", if execution can lead directly from `! to `=". The following three rule contitute an inductive definition [41] of thi relation. ZY [1\]ihjZY [1\;] Definition 2.1 The tranition relation ZY [1\] ) egf and. U li _ Wm./022 POCQ n oe n Wp qs:q n (e n U $.a<6>.=?@br n P n oe n U CU ts:q. In the following, `ki The relation tating when a tack atifie a property i defined in the next ection. For verification purpoe we are intereted in the et of tack that execution can lead to. Given a program with a deignated tart node WE, the operational emantic give rie to the following tranition ytem: ug v Definition 2.2 The trace emantic of de i the et of equence of tack (or execution trace ) reachable from the initial configuration. yxx ZY [1\] ^ Formally, the et of execution trace ww &EzOCQ yxx &E c I}ww a yxx `=E a à~ I}ww ` ~eià~ c! yxx `=E à~ à~ c! I}ww yxx U i inductively defined by: Note that the element of ww are equence of tack i.e., equence of finite equence of node from the flow graph. For technical reaon it i convenient alway to operate on tack with two or more node. For thi reaon, we aume that the graph ) i contrained o that ƒ E, i a ingleton where correpond to the main method of the program and we let the initial tack in the trace be the tack `E &E. It i poible to dipene with the artificial entry node WE at the expene of lightly complicating the correctne proof of the tatic analyi defined in Section 4. 3 Formal definition of ecurity propertie The only way the operational emantic of the previou ection i related to ecurity iue i through the.a<6>.=? intruction. Thi intruction model a programming language mechanim that enforce a ecurity property at a given point in the execution. 5

6 " " ` ` "! ` " " "! Syntax: ˆ Š/Ž$XŠ1 Š&> >!C!d ZY [1\] ZY [1\;] ^, I š } ˆ Š I Š œv[ Z ž ŸˆK `Io ` Š Š œv[ Z `=E ỳ `! Z $ MŠ Š ỳ! 3 ` & [ Z! Z `= y $ ŽW ` ỳ `) [ Z ỳ >!d ỳ Y > ỳ ỳ Semantic: (NP range over node predicate, `I, f ZY [\;] ^ ). Figure 1: Language for the definition of ecurity propertie difficult problem however i to be able to relate a collection of uch local run-time check with a global ecurity goal. It i well known that very trong ecurity contraint on one oftware component can be defeated by ubtle omiion in another cooperating component. nother facet of the problem i that a defenive implementation, involving ecurity check before each procedure call for example, would be extremely inefficient. So, it i deirable to be able to determine tatically that certain check are not neceary to enforce the intended ecurity property. The firt tep to achieve the above goal i to provide a formalim for defining ecurity propertie. In thi ection, we propoe a language to expre ecurity propertie a propertie on et of execution trace (Section 3.1) and we illutrate it expreive power with a collection of well known ecurity propertie (Section 3.3). 3.1 formalim for defining ecurity propertie Since the emantic of a graph i defined a a et whoe element are trace of tack of node, there are three different kind of predicate to conider: 1. Predicate decribing ingle node. 2. Predicate decribing tack of node. 3. Predicate decribing trace of tack. node correpond to a program point o the predicate on node characterie baic ecurity propertie attached to a piece of code like it protection domain or ite of origin. Thee are the predicate that are ranged over by NP in Figure 1. Exactly what predicate are needed depend on the actual ecurity property to formalie o we do not pecify the et of node predicate further. State were defined in the previou ection to be tack, i.e., finite equence of node. We write predicate on uch equence uing a linear-time temporal logic whoe yntax and emantic are defined in Figure 1. The bae predicate of the logic are the node predicate and the et of logical connector include conjunction, negation, 6

7 Š and an until operator ˆ. We lift node predicate to predicate on equence of node ˆ ˆ by tipulating that hold of all thoe equence for which the firt node atifie. Negation Žª ˆ mean that Ÿˆ the negated predicate doe not hold of the equence; in particular mean that i not a property of the firt node in the equence. The formal emantic of the temporal logic formulae i given in Figure 1 and explained in Section 3.2 below. [ Dijunction «, implication and > n can be derived from thi minimal language, uing conjunction, negation, and. uual, we alo introduce the derived } ± [ operator n to expre that hold of all element of a equence and Ž_ ŽWC5 a next operator to expre that mut hold for one element of a equence. Concerning the trace predicate, we have limited our work to afety propertie. Thi retriction i not uncommon in the domain of ecurity propertie ee e.g., the work by Schneider [30] on enforceable ecurity propertie for a dicuion on the topic. The conequence of thi retriction i that all trace predicate are global invariant on the tack in the trace i.e., for a tack property the predicate are of the form hold for all tack in the trace. Since tack predicate are lifted to trace predicate in a unique way, we overload the atifaction relation between tack and tack predicate and write i to mean that the et of trace atifie the property induced by the tack predicate. Formally, thi mean that all tack in all trace in atify. 3.2 Semantic of ecurity propertie In Figure 1 we define the atifaction relation `K that formalie when a equence to denote the length of a ` atifie a predicate. In the definition of Š we ue ` equence `, ` to denote the ³ µ element of ` and ` to repreent the uffix of ` tarting at `. Thu à Š Š/p i the empty equence if ` and ` Š Š i undefined if `. Note that, from the definition of }, the emantic of a formula i defined with repect to a (poibly infinite) et of finite equence ` (each of thee equence will correpond to a poible execution tack of the program). The negation of a formula mean that cannot be proved with the rule defining the emantic of the formulae. In particular, the negation of a node predicate, Ž$ ˆ, hold of all thoe equence where ˆ applied to the firt node of the equence i fale. We ue a weak verion of the until operator!: " in the ene that the definition doe not require that " eventually hold. Thi choice ² i not ignificant however ince the trong verion can be derived from and the operator defined above. We are now in a poition to define what we mean by a program (modelled by a graph) atifie a ecurity property. Šp Definition 3.1 graph atifie a ecurity property, which i denoted by, xx if and only if ww vº. Thi definition to only ueful for verifying propertie of a program if the graph modelling the program correctly reflect the control flow of. Formally, we mut 7

8 Ž Ä Ã require that ww xx contain all the poible execution trace of. Thi i eentially the correctne criterion of the control flow analyi ued for contructing the graph )º from the program. We do not conider the iue of proving correctne of control flow analye in thi article but refer the reader to article pecifically related to thi topic [2, 14, 17, 25]. 3.3 Example of ecurity propertie formalied in our framework Our approach i dedicated to propertie of the control flow of the application. Thi allow u to formalie a number of commonly ued propertie a illutrated by the following four example. The egregation of duty i often required in financial application where ecurity i enured by impoing that a tak cannot be completed unle at leat two principal are involved [13]. In our framework, a principal (or a ubject) i defined by a property which i atified only by the node correponding to program point in it code. We can further gather principal into larger group like Manager, ccountant, etc. The egregation of duty property impoing, for example, that a code of the category Critical can only be executed if backed by a manager and an accountant can be expreed a follow: ¼» Žd ½ Y ½ \[ Žd ½ Y ½ \[ ¾ Á [/Z[ À / \\ ZY [ Y From the emantic of the logic (Figure 1) we have that thi property i atified if and only if all the poible execution tack atify the two following propertie: 1. No node atifying the property Critical occur before the firt node atifying the property Manager. 2. No node atifying the property Critical occur before the firt node atifying the property ccountant. Reource protection can impoe that code from protection domain  can only call code belonging to a domain ƒ via code of protection domain Ã. Identifying the name of a protection domain» with the node predicate belong to», thi property i pecified a follow: Ž Ž 5 ÂT«ƒ In other word, if, for a tack `,  happen to be atified by a node in `, then ƒ à mut hold at that point, which mean that no node from protection domain ƒ can occur after in the tack ` before the firt node coming from domain Ã. The andbox model wa originally propoed a the ecurity model for Java application. The model implie that a dynamically loaded method originating from ite can only call method originating from the ame ite or local method. Uing the \[ property Å& ½ Ý Æ to characterie local node and for node belonging to ite, thi property can be pecified a follow: ¼Ã ǽ Ý Æ (ǽ Ý Æ 8 «oå% \[ 5

9 Ê Ê «Thu, for all node in the call tack, if the node called i from a non-local ite then the next call hould either be to code from the ame ite or back to ome local code (that then can call other ite). Stack inpection i the bai of the ecurity mechanim of the Java Development Kit JDK 1.2. In thi etting, each piece of code i granted a et of permiion to execute certain operation (for example, reading from and writing to a file). If a critical operation op i executed by method }!, then Œ! mut have permiion to do o. Furthermore, if Œ! itelf wa invoked by method ", then P" hould alo have permiion to execute op. In general, the tack inpection policy impoe that an operation op can be executed only if all the code that lead to the execution of op ha the correponding right. Operationally peaking, thi amount to examining the call tack to check that all the method on the call tack have permiion to perform the operation in quetion. Thi policy prevent code from performing an operation on behalf of an unauthoried code. Requiring that all caller have a pecific permiion i in certain cae conidered too retrictive and can be circumvented by deignating certain part of the code a privileged. Marking a method call, " ay, in the body of method i! a privileged mean that all caller (direct or indirect) of }! will be given the permiion held by i executing. For example, an operation in X" body i X! a long a the call P" executed a oon a the method i! and P" have the permiion to do o the caller of! do not need to have thi permiion. In a ene,! take ole reponibility for what happen when the method call " i executed. Stack inpection for a particular permiion in the preence of permiion and privileged code can then be decribed operationally a follow. Examine the tack tarting from it top (which correpond to the method currently executing), performing the following check: 1. if the tack top doe not have the permiion, the tack inpection top and return failure, 2. if the tack top ha the permiion and i marked a privileged then tack inpection top and return ucce, 3. otherwie, if the tack top ha the permiion but i not privileged, pop the top element of the tack and continue the tack inpection on the remaining tack. uming that privileged code ˆ_ ½ÉÈ atifie the property, the tack inpection policy that check for permiion i characteried by the following formula in our formalim: BC$ 5 Œ»qË ² ˆ ½ÌÈ35 C The property impoe that for any execution tack ` and any node in ` ˆ ½ÌÈ, either i atified by a node that follow in ` X ² ˆ ½ÌÈ3 (that i to ay ) or mut atify. Note that ˆ_ ½ÉÈ BC the property»që i formulated ˆ_ ½ÉÈ o that it enforce that the lat node atifying (the node not followed by another node) alo atifie the property. In other word, it ˆ_ ½ÉÈ amount to forgetting the node travered by the code before the lat node atifying occur (if uch a node occur); thi node and all the remaining top node mut then atify. 9

10 Ê Ê There i a ubtle difference in the tack inpection ued by JDK and Internet Explorer (IE) on one hand and Netcape on the other [40]. The difference only manifet itelf on tack in which all tack element atify the property but none of them are Br privileged. JDK and IE accept uch a tack (and»që i true becaue hold globally). Netcape reject uch a tack. Thu, the Netcape tack inpection policy can be reformulated a: there mut exit a privileged call uch that the code containing the call and all method invoked (directly or indirectly) by that call have the property. In term of tack thi mean that there mut exit a privileged node in the tack uch that that node and all node higher up in the control tack have permiion. In our formalim, thi can be expreed in two way. One olution i to add to the JDK policy the extra requirement that there exit a privileged node in the tack. more compact formula expreing the ame i: Y n \[Í3 BC$ ² ˆ ½ÉÈ which tate that there mut exit a node atifying Priv uch that the node itelf and all the following node atify the property. BC The property»îë illutrate the fact that our language can be ued both to expre global.a<63.r? BC ecurity propertie and local propertie that are checked at run time (through the intruction in our programming model). We decribe an application of thi in Section 5. 4 Verification In thi ection we preent a method for verifying that a program (abtracted by a control flow graph, a defined in Section 2) atifie a given ecurity property. Deigning a mechanical verification method i complicated by the fact that the operational emantic of a control flow graph i a poibly infinite-tate tranition ytem. ere, infinity arie from recurion in the program, leading to tack that grow infinitely. nother C node whoe effect i.=<>6>.=?cìï ource of complexity in thi context come from the to cut certain execution trace. In order to get a deciion procedure for ecurity propertie, we propoe a technique for mapping an infinite tranition ytem into a finite ytem which i equivalent to the original ytem with repect to a given property. The core of the verification technique i a calculation of the et of reachable tate of an abtraction of the infinite tranition ytem. The abtract tranition ytem i obtained by partitioning the infinite tate-pace into a finite number of equivalence clae Ï according to the global ecurity property to verify and each of the propertie from the check node in the program control flow graph. The partitioning i defined by an equivalence relation on tack cðï that equate two tack if they atify the aðï ame et of propertie among the propertie! ~. Thu, by contruction, thi reult in a finite number of equivalence clae. The main theorem to be proved here tate that a property hold of the original, unabtracted ytem if and only if it hold of the finite, abtracted ytem. ence reaoning with the finite ytem uffice to decide whether the property hold. 10

11 Â Â Õ E E Â Â Ü I 4.1 Finite automata repreentation of propertie The verification technique i baed on a reult due to Vardi and Wolper (ee e.g., [34, 33]) which tate that there exit a tranlation from formulae of linear temporal logic to determinitic finite-tate automata uch that a tring atifie a formula if and only if the tring i accepted by the correponding automaton. The Vardi-Wolper tranlation deal with temporal logic over infinite tring which are tranlated into Büchi automata. ere, we interpret the formulae over finite tring. Thi change the acceptance condition for the automata lightly but the tranlation technique remain the ame. Since the following reult only depend on the exitence of uch a tranlation, and not on how it i defined, we omit a more detailed decription and refer to [33]. Example of formulae and their tranlation into automata can be found in Figure 10 and Figure 11. The automata play a central role in the verification algorithm. The algorithm tran- Ï late the global property and all locally checked propertie into automata, written Â Ñ ÂzÒ Ó. It then proceed by following all poible path in the control flow graph, letting the automata evolve imultaneouly. Ï.a<6>.=?CÌÏ When reaching a node it i then immediate to decide whether hold by checking whether the correponding automaton ÂÔÒ Ó i in an accepting tate. Similarly, the property hold globally if the automaton ÂyÑ i in an accepting tate all the time. The following definition fix the notation ued for automata. Definition Õ 4.1 determinitic finite tate automaton ÚØÚ Â ÕKÖ Ø zù ØÚ i a quintuple E where i a finite et of tate ranged over by, Ö i a finite alphabet ranged over by Û Û, f Ù i the et of final tate, Ñ Ú the tranition function, and E the initial tate.  i overloaded to denote the function that map each tring ÜMI Ö ^ Ö ^ JÕ to the tate reached by the the automaton after reading Ü. Let Û denote the th element of a tring Ý. The function  i defined by > $ßÙ > Û E bßù Ú ÛRÞ Û E ÛRÞ à! ÛRÞ ÛE ÛE Notice that the function  i well defined becaue the automaton  i determinitic. n automaton recogniing the et of tring atifying a linear temporal logic formula á will be written  â. We tre that thi automaton i not uniquely determined but we aume for the ret of the article that a particular tranlation for each property i choen. Definition 4.2 Let á be a linear time temporal logic formula a defined in Figure 1. M Õ We ue Ÿâ â Ö Ø â Ù â ØÚ â to denote a determinitic finite tate automaton that accept the et of tring atifying the property á. Formally, Âãâ mut atify that for Ö all ÜmI ^, ½ ä Ü+qá ÂÔâ â 11

12 x ` I Ü! Ü! ` Ñ h Ü ~ We extend the notation to tuple å defined to be the product automaton Âvâ3é obtain the aociated function Ÿè æ ççç C áz! hizhá Ÿâê Ö ÂÔè ^ ë Õ hœh Õ ì R Ÿâ3é Ÿâí where Õ i the et of tate of the automaton Âvâ Ó. 4.2 The equivalence relation on tack of propertie. Formally, Âyè i  Ñ. For Ü a finite tring we Next, we define an equivalence relation on tack that partition the et of tack into a finite number of equivalence clae. The equivalence relation i baed on the automata repreentation of ecurity propertie and the finitene of the et of equivalence clae will form the bai of a deciion algorithm for ecurity propertie, outlined in Section 4.3. The key idea behind the equivalence relation i that equivalent tack 5 tatement and the global property..=<>6>.=?rìï will have the ame behaviour againt Ï Concretely, equivalent tack will take each of the automata correponding to and á into the ame tate. Thi equivalence i refined in order to incorporate ome additional./022 control flow information into the equivalence clae. In order to be able to match and tatement, we require that the two top element of the tack mut be identical in order for two tack to be equivalent. Definition 4.3 Let å ÌÏ ççç=ðï C be a finite tuple of propertie where i the Ï global afety property to enure and the afety property aociated with the г µ check :Y [1\;]@hXZY [1\] tatement. The equivalence relation îf îß` U ½ ä Ÿè W i defined a follow: n eential property of the equivalence relation i the finite ymbolic repreentation of an equivalence cla a a triple ïð Õ Ò é hœzhpõ The number of equivalence clae i finite becaue: the number of node of the flow graph i finite; Ò ê h Õ ÂŸè ` U _h@ñ ò óôhoñ ò óô/ the number of afety propertie (propertie in check node and the global ecurity property to verify) i finite; and the number of tate of each correponding automaton i finite. Definition 4.4 The tack ` ` U We write wõ` for the equivalence cla of `. belong to the equivalence cla Âvè ïð Intuitively, a triple contain the following information. Execution i at node which belong to a method invoked at node. t the moment of invocation at node, the control tack (of form ` U ) atified that Ÿè ` U $pïð ` U. 12

13 x x Ñ I Ñ Ñ I Ñ x I ï i a tuple of automata tate where a component i an accepting tate if and only if the tack ` atifie the correponding ecurity property. ence, ï an equivalence atifie the global property if the component of correponding ïð cla to the Â Ñ automaton reache a final tate after executing. We hall overload the ymbol to mean both that a tack and an equivalence cla atify a property. Definition 4.5 For a given graph and a global property (with aociated automaton Â Ñ ), we write ïð when ïö Ú Ò é ØÚ Ò ê ØÚ Ñ [ Z Ù Similarly, ï ïð an equivalence cla Ï atifie a property if the ³ µ component of correponding to the ÂŸÒ Ó automaton reache a final tate after executing. Lemma 4.6 Proof Let ïö ` definition, It follow that ` and only if wõ` àu Ÿè 4.3 Reachability nalyi wõ` `Ÿ c Ú Ñ xvj ïð be a tring and $ Ú wõ` ` U Ò é =ØÚ Ò ê ØÚ Ñ ÂŸÑ ` U WßÙ Â Ñ ` U $+Ù if and only if ÂvÑ àu and Lemma 4.6 i verified. xx ø. We have Ú Ñ it equivalence cla. By Ñ ) if and only if Ù Ñ We now define a et ww of reachable equivalence clae that i ued to decide whether all the reachable tack in the program modelled by atify the global property. The et ww i defined inductively by the rule decribed in Fig 2. ere, WE xx ø i the initial node of the graph and the unique node called from the initial node &E. Since %E i the firt reachable tack, it equivalence cla w ¼E i the initially reachable equivalence cla. It ymbolic repreentation i: BÙ5 Ú Ò é E =ØÚ Ò ê E ØÚ Ñ E &E &E Becaue the et of equivalence clae i finite, it i decidable whether an equivalence cla belong to ww. Together with the following theorem thi provide a xx ø procedure for deciding whether a program atifie a global property. Ú Ñ Ñ if Theorem 4.7 xx ww :ù xx øúù I ww 13

14 û x x I û û ù E x E x E x x ù x Ï x &EzOCQ BÙ5 Ú Ò é aøú Ò ê ØÚ Ñ &E &E bð./022 ü% BÙ POCQ yxx I}ww ø $p ü% yxxìø Ù tsrq U ü% I}ww yxx U I}ww ø Wð.=<63.R?CÌÏZý ü% ts:q ü% CU yxx U I}ww ø xx I}ww ø xx ø Iiww $ßñ yxx ø Iiww ü% ñ yxxìø I}ww Figure 2: Inductive definition of the et of reachable equivalence clae Proof: The proof i divided into two part that can be viewed a a correctne (the þ ) and a completene (the ) part of the analyi. Section 4.4 how that the abtract tranition ytem on equivalence clae i a afe approximation of the concrete tranition ytem while Section 4.5 how that the et of reachable equivalence clae cover ufficiently many tack to account for all poible behaviour of the program with repect to the global property. Formally, we prove the following two propertie: xx ø Ðœa àeeôÿ¼ỳ ìwõ` yxx ø Iiww ù) 1 I}ww àui ` E eôÿ¼àu We can then ù prove the theorem a follow. For correctne, aume that all equivalence xx ø clae I±ww ù xx atifie and let `ŒI ww i.e., `REveŸÿ_` Ðœa. From we get yxxìø that wõ` ww and hence that wõ`. Lemma 4.6 then implie that `Œ. For completene, ù yxx aume that ww i.e., that for all ` uch that `1EeÔÿ¼` we have ỳ. xxbø Let be an equivalence cla in ww 1. By there exit a ` U I uch that `=Ece ÿ ` U. By aumption, `=U ù and and Lemma 4.6 then implie that wõ`ru. 4.4 Correctne We prove that the abtract tranition ytem i a afe approximation of the concrete one in the ene that for all reachable tack `, the correponding equivalence cla xx ø wõ` belong to ww. Lemma 4.8 `=Ee ÿ `Ÿ wõ` xx ø I ww We prove the lemma by induction over the derivation length. Suppoe that xx ø xx ø `E%ez &` wõ` I}ww ; we how that if ` E ez ` e}` c! then wõ` c! I ww. The tranition ` eß` c! i determined by the type of node on top of `. We conider each poibility in turn. 14

15 x ` û û ` ù û ` ` I Ï x Ï x x x I I I.1022 node $m./022 ü% x ü% xxìø Suppoe that `REŸe ` ` U. By induction hypothei, ür wõ` I ww where  è àu By the rule for node in the operational emantic (Definition 2.1), ` e ` U Similarly, by the rule for node in the definition of ü% xxìø ww ùm BÙ xx ø (Figure 2) we have I}ww. Furthermore, ù BÙ ÂÔè ` U üc bm Ÿè ` U ü% W wõ` U ü% ü% yxx ø ence, wõàu I}ww./022 and the property hold for node node $p Suppoe that `=Eez ` e i prefix-cloed in the ene that for all prefixe Ü of ` there exit uch üc that `=E eü. It follow that ` EÔe ` U with. By applying twice x$ ñ xx ø xb ü% the induction hypothei, we obtain wõ` Ißww and w xxìø ww ñ üc where Ÿè ` U Ù üc and Ÿè ` U ü%. By the rule, ` e ` U U. ü% W+ñ Moreover, the precondition Âyè ` U hold and by the rule, ù ü% yxx ø CU I}ww. By definition of the equivalence relation, wõ` U ü% U x: ÂÔè ` U üc ü% U b ü% U $+ù) ü% x xxìø ence, wõ` U U I}ww and the property hold for node. POCQ ts:q U. It i traightforward to ee that the tranition relation.=<>6>.=? node Wð.=<63.R?CÌÏZý S:Q U ü% xbæ ü% Suppoe that `REŸe ` ` U. By induction hypothei, xx ø ür wõ` ww where Ÿè ` U. From Lemma 4.6, we have wõ`. By the.a<63.r? rule üc `e àu CU üc xx ø and CU I±ww ü% ž ü% ü%. Since &U wõàu CU we have xxìø wõàu CU ww.a<63.r? and the property hold for node. 4.5 Completene The completene part of Theorem 4.7 tate that for each reachable equivalence cla, there exit at leat one reachable repreentative: xx ø I}ww ù) àe_e ÿ The proof i given in Section In order to prove thi reult, we need the following lemma. Intuitively, it tate that method call preent in the et of abtract tate correpond to call at the concrete level. Lemma 4.9 üc BÙ `=EeÔÿ¼` xx ø Iiww xxìø ü% I ww ü% ŒI `=Ee ÿ ` ü% 15

16 ~ û ~ ~ :p:n º lemma :p:n:o º ~ º ~ &% :p:n:m lemma :p:n:o:q º! "$ ~ Figure 3: Lemma 4.9 and node Proof The proof of the lemma i by induction over the deduction of BÙ xx ø I}ww. In the following, a figure decribe the ituation for each of the derivation rule. The convention are: Filled node repreent equivalence clae given by the induction hypothei. The white node i a newly deduced equivalence cla. Dahed arrow, labelled by lemma, figure out ue of induction hypothee. Bold arrow link equivalence clae ü% and BÙ Simple arrow are labelled by tranition rule.1022, ,.a<6>.=?. Bae cae The proof of the property for the rule concerning the initial node be can be reformulated a follow. J`=Ee ÿ ü% ` &E üc xxìø BÙ &E I}ww &Eüc &E ` E eôÿ¼` E I xx ø I ww ü% E ü Thi i vacuouly true ince there i no uch that xx ø i een by inpecting the rule defining the et ww Induction tep.1022 node Let BÙ xx ø I ww. ü% WE xxìø Ikww.. Thi latter fact./022 be deduced from a rule. a reult, there exit a node in the flow graph uch that: bð./022 POCQ ü% xx ø ü% Suppoe that Ilww uch that ü% `=EeÔÿ ` I ` E eÿÿw` ence lemma 4.9 hold for node. üc. By./022 rule, 16

17 Ï I I Ï Ï ;=< <, )(+(-, lemma >? ;=<,7@ <, <B.0/12/435/76 >? ;=<,7@ <, < : (+(8,9(8: check Figure 4: Lemma 4.9 and.a<63.r? node BÙ xxéø node Let ww û hypothee of thi rule yield that there exit a node in the flow-graph and two deduction: BÙ BÙBÙ Øò1 xx ø Øò1ØòØÚ1 I}ww yxxìø Iiww be deduced from a rule. The Ú !C Ðœa, an edge ò S:Q The other hypothee from the lemma are: ü% ` E eôÿ¼` xx ø üc Iiww ŒI 1 ü% D1 Lemma 4.9 i now applied twice in order to prove the property. Firt, from (2),(3),(0) ü% úò we deduce that `RE>e ÿ ` Second, thi fact together with the fact (0) and (1) imply ü% úòúú that `=EeÔÿ%` ü%. By the rule, `REbeŸÿ%`. ence Lemma 4.9 hold for node..=<>6>.=? BÙ xx ø node Let û Igww ò/p-.a<6>.=?&ìï ý there exit a node ò, a tranfer edge BÙ Øò1 xxìø!c S:Q I ww BÙ Øò1 uch that lemma are ü% xxìø Ðœa ü% I ww üc 1 àeeôÿw` ŒI By Lemma 4.9, from hypothee (1), (2), (0), we deduce that àee ÿ ` ü% úò BÙ be deduced from a.=<>6>.=? rule. BÙ By the contruction of the equivalence clae and the fact that üc úò we get that `. a reult, by the.a<63.r? ü% úò rule, ` e ÿb` Lemma 4.9 hold for.=<>6>.r? rule. Thu and a deduction. The other hypothee of the Øò1 ü% Øò/. ence, Completene Proof The completene proof now proceed by induction on the derivation of ù xxçøô I ww 17

18 ` ` Ï û û I ` I Ï Ï.1022 BÙ yxx ø node Let û ww exit a node y(./022 üc xxéø a deduction üc ü% Ikww `=EveÔÿ_` mi./022. By the rule, ` equivalence relation wõ` ü%.1022 be deduced by rule. ence, there and an edge OCQ belonging to the flow-graph. and. By induction hypothei, there exit a reachable tack ü% ü% }eÿÿ_`. By definition of the x: ÂÔè ü% $ BÙ We conclude that the property hold for.1022 node node Let ü% &U xx ø Ilww be deduced by the rule. Then, the following node and edge belong to the flow-graph: Moreover, there exit two deduction $p ü% xx ø I ww BÙ xx ø I ww ü% ü% and by induction hypothei a reachable tack ` E eôÿz` I. By lemma üc 4.9, there exit `REze ÿ ` BÙ repreentative of By the rule ü% ü% ü% x: ü% me@` CU. By definition of the equivalence relation, wõ` and the property hold for node..=<>6>.=? node Let ü% U yxxìø I ww.a<63.r? be deduced by the rule. The following node and edge belong to the flow-graph: bð.a<6>.=?&ìïý tsrq U ü% yxx ø Moreover, there exit a deduction ww ü% uch that. By üc ü% induction hypothei, there exit a reachable tack `1Ee ÿ ` I. Since ü% ü% it follow from Lemma 4.6 that ` }. a reult, by.=<63.r? rule ü% ü% üc xb( ü% ek` CU and by equivalence definition, wõ` %U CU. We conclude that the property hold for.a<63.r? node. Thi conclude the completene proof. 4.6 Complexity of the verification method Definition 2 directly tranlate into an iterative algorithm that calculate ww by repeatedly applying the inference rule until no new abtract tate can be added. The xx ø number of iteration tep for contructing ww i bounded by the ize of the et of abtract tate. n upper bound on the ize of thi et can be determined a follow. Let W[ É be the number of node in the control flow graph, be the number of call node in the flow bˆ FE \;] graph and be the number of check node in the program. Let furthermore be the ize of the automaton decribing the global property to verify. Then the number of poible (abtract) tate i bounded by W[ É n h ts:q n hgijlk!m Nh 18 U xx ø

19 The exponential factor come from the fact that there are two tate in the automaton correponding to a check node in the program and that each check node give rie to an automaton that tell whether the given property at that check node i atified or not. firt reduction of the tate pace would be to have one automaton for each check property uch that check node with the ame property FE Ø\] hare the ame automaton. Furthermore, it hould be noted that the number of check node i uually much maller than the ize of the program. The example that we preent in Section 6 how that the upper bound given above i not very accurate. It predict in the order of ten thouand tate for the example wherea the real number i twenty-ix. Thu even a relatively ecurity-intenive program a the one ued in the example (ee Figure 9) only explore a relatively mall part of the tate pace. yxx ø The number of tate in ww reflect quite accurately the number of different combination of permiion that different part of the program have. In the extreme cae of all code having the ame et of permiion, the exponential factor in the formula above can be replaced by 1 ince none of the automata change tate. the program travere more and more protection domain (and hence the et of held permiion change more frequently) more and more of the abtract tate pace will be explored. Thu a program with a rich ecurity tructure will be more complex to verify, a one would expect. 5 pplication to the Java Development Kit The Java Development Kit JDK i one of the mot prominent propoal for language baed ecurity management. In thi ection we how how the JDK 1.2 ecurity mechanim can be decribed in our framework. The next ection provide an illutration of the model through an electronic commerce example. The JDK 1.2 ecurity model aign protection domain to code baed on it ignature and define the ecurity property a a global aignment of permiion to protection domain. The virtual machine doe not verify the permiion itelf, but the tandard library provide the pecial cla ccecontroller with a number of ecurity related method. Of thee, checkpermiion verifie that a given permiion i granted in the given context, and throw an exception if not. For a permiion to be granted, all the method on the call tack mut have the permiion granted. thi i too retrictive in general, the ability i provided to mark certain call a privileged, which temporarily dicard all of the previou caller from a permiion checking point of view. The aignment of a protection domain to a given piece of code mean that each node in the correponding graph belong to a protection domain. We tipulate that a node atifie the property ha permiion if it belong to a protection domain with permiion. Furthermore, a node correponding to a privileged call i aigned the pecial property Priv. owever, being privileged or not i a dynamic property in Java 1.2 [12, 15], enabled with the method call beginprivileged and diabled with the method call endprivileged wherea in our model it i a tatic property of the code. We make the aumption (true of all the example we have een) that we can tatically identify the privileged code, thu diallowing call to endprivileged under dynamic control. Call to beginprivileged and endprivileged diap- 19

20 O pear in our model, but the node delimited by the two are recorded a atifying the property Priv). In the latet verion of the JDK (2.0), the begin-/endprivileged pair ha been deprecated and replaced by the method doprivileged. The doprivileged method i a afer way of deignating part of code a privileged compared to the earlier begin/endprivileged block where pecial care had to be taken to make ure that end- Privileged wa alway called appropriately (notably in the preence of exception). call to doprivileged take a argument an object of a cla that implement the interface Privilegedction. Thi interface contain one method, run, which i reponible for calling thoe method that are to be executed in privileged mode. In order to handle a call doprivileged(o) where O i of cla C which implement the interface Privilegedction, the initial control flow analyi mut repreent uch a call by a privileged call node (i.e., a call node having the permiion Priv) that ha a call edge to the run method of cla C. call to checkpermiion(perm).a<63.r?rboqpsri ˆŸ ; LTq5 from cla ccecontroller can then be modelled by the intruction with OPSR a defined at the end of Section Contructing the control flow graph To obtain the graph correponding to a Java program, it code i tranformed into baic block and everything but method call i abtracted away. indicated in Section 2, the contruction of the call edge in the control flow graph ue a data flow analyi that for each variable find an over-approximation of the clae of the object that are being tored in the variable. For each call node correponding to a virtual method call of the form X.m() and for each poible cla C of the object tored in X we introduce an edge OCQ to the entry node of the method named m in C. number of uch analye have been propoed. The implet analyi approximate the et of poible clae by all the ubclae of the declared type for the variable. imple improvement, called rapid type analyi [2] wa propoed by Bacon and Sweeney. It conit in interecting the et of ubclae with an approximation of the et of clae that are actually being intantiated during execution. Thi analyi can deal with large program and i generally conidered to give acceptable reult. Thee analye do not conider the data flow of the program. Thi apect i taken into account in the contraint baed analyi propoed by Palberg and Schwartzbach [26, 25]. In it baic formulation, the analyi doe not take the equential control flow of the program into account ince it only calculate one global approximation for each variable. Thu it preciion can be further improved by ditinguihing between different occurrence of a variable, rendering the analyi flow-enitive a propoed by Pande and Ryder [27]. prototype implementation of the verification technique [32] ha been developed uing the flow-inenitive contraint baed analyi, adapted to take the viibility modifier of Java into account. The next ection decribe a mall example that wa analyed automatically by thi prototype. 20

21 1 public cla ControlledVar { 2 private float var; 3 void write(float new) { 4 ccecontroller.checkpermiion(write); 5 var = new; 6 } 7 float read() { 8 ccecontroller.checkpermiion(read); 9 return var; 10 } 11 } Figure 5: The ytem code (Sytem domain) 6 Electronic commerce example In thi ection we illutrate the concept involved through an electronic commerce example. Four protection domain (correponding to four principal) are involved. They are called Sytem, Provider, Client, and Unknown: We aume the ytem (Figure 5) upplie code to implement a controlled floating point variable. Thi variable ha entry point for read and write operation, protected with a check for the repective permiion. The ytem alo upplie a main method (not hown), erving a an initial entry point to the application. Uing the controlled variable, the ervice provider build an account manager (Figure 6) with a debit tranaction and a boolean query method canpay. For thi to work, we aume that the provider i granted the Write, Read, Debit, and the Canpay permiion. The debit and canpay method call read and write in a privileged mode becaue they can be called by client which do not have the permiion to call read and write directly (i.e., which are not granted the Read and Write permiion). Completing the application, the client build an application on top of the account manager (Figure 7). We do not detail the application, but the idea i one of an interactive front-end to the account. The client i aumed to be granted the Debit and the Canpay permiion. To illutrate the handling of illegal code, trying to execute unauthoried operation, we include an intruder (Figure 8) without any permiion. 6.1 Tranlation of the example into our model From the code for the above example, we derive the graph U a outlined in the O previou ection. The reult i hown in Figure 9. lthough the method have no repreentation in the graph, we have clutered the node in boxe according to their method of origin. Furthermore, boxe are coloured according to the protection domain to which it node belong. The dotted edge are tranfer edge (TG), while the 21

22 12 public cla ccountman { 13 private ControlledVar balance; 14 public boolean canpay(float amount) { 15 ccecontroller.checkpermiion(canpay); 16 boolean re = fale; 17 try { 18 ccecontroller.beginprivileged(); 19 re = balance.read() > amount; 20 } finally { 21 ccecontroller.endprivileged(); 22 } 23 return re; 24 } 25 public void debit(float amount) { 26 ccecontroller.checkpermiion(debit); 27 if (thi.canpay(amount)) { 28 try { 29 ccecontroller.beginprivileged(); 30 balance.write(balance.read() - amount); 31 } finally { 32 ccecontroller.endprivileged(); 33 } 34 } ele } 36 } Figure 6: The account manager code (Provider domain) 22

23 37 public void pender() { 38 float pend =...; 39 if (account.canpay(pend)) { 40 account.debit(pend); 41 } 42 pender(); 43 } Figure 7: The application code (Client domain) 44 public void clyde() { 45 account.debit( ); 46 clyde(); 47 } Figure 8: n uncertified application (Unknown domain) olid edge are call edge (CG), obtained through a cla analyi. The three encircled node correpond to code executed a privileged. The four protection domain partition the et of node a follow: d ½ ;ZY ˆ Èa½B 7\ n Ý ]T b >]= c &V WV YX a YZ ¼![X &E ¼! &" Y^ d_ Each node in the graph U atifie a property correponding to it protection domain, plu the property Priv if it appear within a privileged ection. We ue the fol- O lowing convention for naming node propertie: belonging to a Java protection domain Dom mean atifying the property»fedgih, having a Java permiion Perm mean atifying kj K`l ù h. Furthermore, we write h K`mnJ for the property which i true only for node of the Java method meth. The propertie aociated with each protection domain are:» Qo pk`q]m e Kr[pnm utiqiv"tw» j l gix p yk`l e KBr[pnm utiqivltiw kz Kty S{ l pm K»0} wi~!m K h e KBr[pnm utiqivltiw kz Kty S{ l pm K >» qlniq gi q In addition, the node Fa, ¼! V, and W! V are privileged i.e., atify the property Priv. 6.2 Verification of ecurity propertie a global tatement about the ecurity of the ytem, we tate that all the call leading to a modification of the balance mut poe the Debit permiion and all the call leading to dicloure of the balance mut poe the Canpay permiion. Thi ¼![^ ¼!`_ ¼![Z ¼![a 23