Data-Centric Security: Role Analysis and Role Typestates
Vugranam C. Sreedhar IBM TJ Watson Research Center Hawthorne, NY, USA [email protected]
ABSTRACT General Terms In J2EE and .NET roles are assigned to methods using ex- Languages, Security ternal configuration files, called the deployment descriptors. Assigning roles to methods, although conceptually simple, Keywords in practice it is quite complicated. For instance, in order for a deployer to assign a role r to a method m, the de- RBAC, Role Analysis, Role Typestates, Role Escape Analy- ployer must understand the set of roles R that are assigned sis to each method n that can be invoked directly or indirectly from m, and that r has to be “consistently” assigned with 1. INTRODUCTION respect R. Understanding such role consistency is a non- Role Based Access Control (RBAC) is a popular mech- trivial task. Also, in J2EE roles are defined with respect to anism for defining and managing access to security sensi- method access and not data access. Therefore, in order to tive resources [9, 26, 10]. In RBAC, security properties, protect sensitive data, one has to encode data access control such as access control to sensitive resources, are controlled using method access control. This can lead to interesting through roles. Users are assigned with one or more roles, and subtle access control problems when accessing sensitive who then inherit the security properties associated with the data, including information leakage through data flow from roles. RBAC provides greater security by preventing users one method to another. from obtaining inconsistent or incompatible security proper- In this paper we focus on data-centric security by present- ties. J2EE [1] and .NET [17] support RBAC by restricting ing two concepts: the roles to method access.12 In J2EE a role r is simply • Role Analysis: We present a simple interprocedural a named set of methods M, and whenever a principal p is assigned the role r the principal can then access any of the static analysis for detecting security problems when 3 objects are accessed by multiple methods that do not methods in M. In J2EE, there are two ways to specify have compatible or consistent assignment of roles. We access control security: (1) declarative or container security then introduce the notion of an object “escaping” a and (2) programmatic or application security. In container role and present a simple interprocedural static analy- security, access control to sensitive resources are defined in sis for computing the set of objects that may escape a an external configuration file, as part of a deployment de- role. scriptor. The container then manages the access control to sensitive resources. In application security, access con- trols are encoded within the application and the application • Consistency-Based Security and Role Typestates: directly manages the access control to sensitive resources. We extend J2EE method-based role assignment to The J2EE framework encourages the use of declarative se- consistency-based role assignment. In this paper we curity since it enables greater flexibility by separating se- will focus on assigning roles to typestates rather than curity properties from the application logic. We will use methods. declarative security in our discussions. To illustrate how security roles are defined in J2EE, con- Categories and Subject Descriptors sider an example application of the Observer Pattern shown in Figure 1 [13]. The Observer Pattern is made of two enti- D.3.3 [Programming Languages]: Language Constructs ties: a subject that contains data of interest and (2) one or and Features more observers that display the data of interest. The Ob- server Pattern defines a one-to-many dependency between 1The security model of J2EE and .NET are quite similar, Permission to make digital or hard copies of all or part of this work for and for simplicity we will illustrate our examples using the personal or classroom use is granted without fee provided that copies are Java programming language. not made or distributed for profit or commercial advantage and that copies 2J2EETM and the JavaTM programming language are the bear this notice and the full citation on the first page. To copy otherwise, to TM republish, to post on servers or to redistribute to lists, requires prior specific trademark of the Sun Microsystems. .NET is a trade- mark of the Microsoft Corporation. permission and/or a fee. 3 SACMAT’06, June 7–9, 2006, Lake Tahoe, California, USA. In practice only application entry methods are assigned Copyright 2006 ACM 1-59593-354-9/06/0006 ...$5.00. roles (see also Section 2.2).
170
20:class Subject implements ISubject{ 21: private ArrayList obsList; 22: private Data data; 47:class Data{ 23: Subject() { 48: String name ; 1: interface IObserver{ 24: obsList = new ArrayList() ; 49: int id ; 2: void update(Data info); 25: data = new Data() ; 50: Data(){ } ; 3:} 26: } 51: printName(){ 4: interface ISubject{ 27: setData(String name, int id){ 52: System.out.print(name) ; 5: void addObs(IObserver obs); 28: dat.name = name ; 53: } 6: void removeObs 29: data.id = id ; 54: printId(){ 7:} 30: notifyObs() ; 55: System.out.print(id) ; 8:class ObsId implements IObserver{ 31: } 56: } 9: ObsId(){} ; 32: void addObs(IObserver obs){ 57: } 10: void update(Data info){ 33: obsList.add(obs); 58: class Driver { 11: info.printId() ; 34: } 59 public static void main(String[] args) 12: } 35: void removeObs(IObserver obs){ 60: { 13:} 36: obsList.remove(obs); 61: Subject sub = new Subject(); 14:class ObsName implements IObserver{ 37: } 62: ObserverId oid = new ObsId() ; 15: ObsName(){} ; 38: private void notifyObs(){ 63: sub.addObs(oid) ; 16: void update(Data info){ 39: for(int i = 0; 64: ObsName oname = new ObsName() ; 17: info.printName() ; 40: i
171
172
Figure 3: Call graph for the example program shown in Figure 1.
tions, and (3) permissions that maps a role to a set of op- to more than one role. Let Rolei(m) denote the set of erations or methods defined in one or more classes.7 For roles that an application deployer initially assigns to m. In instance, consider the Subject class that contains the meth- other words, Rolei(m) = {r|m ∈ P eri(r)}. For instance, ods setData, addObs, removeObs, and notifyObs. A role Rolei(Subject.setData) = {Notifier, Director}. Now if a such as Notifier (see Figure 2) is given the permission method is not explicitly assigned to any role, then it can be to invoke setData. On the other hand a role such as accessed by any principal. Note that one can also use the Director is given the permission to invoke all four oper- ∗ to indicate all the methods in a class as belonging to a ations. Notice that a principal with Director role can in- specific role. voke any operation that a principal with a Manager role or a Notifier role can invoke. In other words, Director is considered to be “senior” to Manager and Notifier [10]. 3. ROLE ANALYSIS Let C denote a set of classes for which we want to pro- In this section we present two role analyses: (1) role con- vide RBAC and let M denote a set of methods in C.A sistency analysis for computing consistent role assignment permission P er is a mapping from role r ∈ R to a sub- and (2) role escape analysis for computing the set of objects set of methods in M. Now let P er(r) denote the set of that may escape a role. method permissions assigned to a role r. For instance, P er(Manager) = {Subject.addObs, Subject.removeObs} 3.1 Role Consistency Analysis Let r be a role assigned to m (by an application deployer), Definition 1 (Senior Roles). Let r and s be any two and let m0 be a method that can be invoked directly or in- roles in R. We say that r is a senior role of s, denoted as directly from m. A principal who is assigned the role r r s, if P er(r) ⊇ P er(s). should also have permission to invoke the method m0, i.e., 0 We can conversely define junior role as follows: r s m should also be in P er(r). Often an application deployer if P er(r) ⊆ P er(s). Next we define a role graph in which has handle to only entry methods of an application or a com- ponent. These entry methods are essentially the application nodes represent roles and edges represent the senior (junior) 8 relations. In this paper we will assume that the role graph programming interface (API) of the application. Therefore form a lattice structure, with > representing a role that is an application deployer has the capability to define permis- the union of all method permissions and ⊥ representing a sion sets and assign roles only based on the entry methods role whose permission set is the empty set [10]. A lattice defined in an API. Let A be an application, let Me be a set is a partial order with a join and a meet for every pair of of entry methods to A (as defined in its API), and R be the nodes. Given any two nodes x and y, the set union of x and set of roles defined using the entry methods. Figure 5 illus- y is the join (t), and the set intersection of x and y is the trates the application or component model. Notice that an meet (u). entry method such as m1 can directly or indirectly invoke another entry method m2. The key question to ask is: how Now let P eri(r) be a set of method permission that is initially assigned a role r (as specified in the deployment de- to define consistent roles and permission sets that is based scriptor). In J2EE a method permission can be assigned on only the entry methods of an application? Consider an 7In J2EE roles are often defined for Enterprise JavaBeans 8In the case of a Java application, the entry methods are the (EJBs), and in this paper for simplicity, we will simply use set of public and protected methods defined in interfaces Java classes instead of EJBs. and classes.
173
Figure 4: Pointer graph for the example program shown in Figure 1.
entry method m1 ∈ Me and let r1 ∈ R. Now let us define r1 to include m1 in its permission set, that is m1 ∈ P er(r1), and therefore r1 ∈ Role(m1) (see Figure 5). What this essentially means is that if a principal p is assigned the r1, then p has the permission to invoke m1. Now let m2 be some other method reachable from m1, and so p should also have the permission to invoke m2. Let P er(r2) = {m2, m3}, and so m2 ∈ Role(r2). We have to ensure that r1 and r2 have consistent permission set. There are two cases to consider:
• m2 is not in P er(r1), and in this case p should also be assigned the role r2 so as to avoid access control exception. On one hand, by assigning r2 to p, we also give p the permission to access m3, which violates the principle of least privilege. On the other hand, m3 may be in different sub-component, in which case sep- Figure 5: An application model with entry methods arating the roles makes sense in some situations, even and role assignments. if the principle of least privilege is violated.
• m2 is in P er(r1), and in this case the assignment is Subject.setData the principal not only needs the Notifier, consistent. but also DisplayId and DisplayName roles. In the Figure 6 we have annotated the call graph with Role and Role+, One way to compute consistent role assignment is to first i which are the initial role assignments and the minimum roles determine the set of methods that are reachable from an needed to invoked the methods. Computing Role+ for each entry point in the call graph of the program. Let L be method is a straightforward backward propagation of roles the set of methods that are reachable from an entry point over the call graph and at each step we only propagation m ∈ M in the call graph. Let L0 = L ∩ M , and so L0 e m e m junior roles up the call graph. That is, we perform a lattice is a set of methods that are reachable from m and the set join at each step and propagate the joined role information. of method are also entry methods. Now let r be a role with The role analysis described previously is based on reach- m ∈ P er(r). Since a method l0 ∈ L0 is also reachable m ability over call graph of a program. Although role prop- from m, we have to ensure that l0 ∈ P er(r). So rather than agation over call graph is important in preventing certain defining arbitrary roles and permission set, a deployer first kinds of access control problems, it does not detect access computes L0 for each entry method m. The deployer can m problems that could happen due to data flow across meth- then define roles based on the entry method m and L0 by m ods.9 Subtle problems may arise due to data flow across ensuring that L0 ⊆ Role(m). m methods. For instance, the receiver expression (such as Typically applications are composed of many components and the components must be assigned with consistent roles. 9A limitation of J2EE security model is that it focuses on Consider the example shown in Figure 1 and the role as- securing the mechanism (that is, methods) that access sen- signment shown in Figure 2. Let Rolei denote the initial sitive information or resources. For instance, J2EE does not set of role assignments. In order for a principal to invoke allow one to specify roles for class fields and class instances.
174
+ Figure 6: Call graph annotated with Rolei and Role for each method.
43: obs.update(data) can target more than one method. objects that escape the life time of a method or a thread. We have to make sure that the roles assigned to the target Consider the following simple example: method is consistent with the role assigned to method that invokes the object. 1: void foo() { Also, an object is often accessed by multiple methods that 2: LinkedList head = new LinkedList() ; have different roles assigned to them. Consider the points- 3: bar(head) ; to graph shown in Figure 4 and in particular the object 4: } 62:ObsId. This object is directly accessed by the meth- 5: void bar(LinkedList h){ ods Driver.main (which created the object), ObsId.update 6: LinkedList n = new LinkedList() ; (via the this parameter), and Subject.notifyObs. Now 7: n.next = null ; consider the role assignment and method permission shown 8: h.next = n ; in Figure 6. The method ObsId.update is assigned only to 9: } role Display. Unfortunately since the object 62:ObsId is also accessed by other methods, there can be inconsistencies The object 6:bar.LinkedList created at 6: escapes the among roles assigned to different methods that access the method bar because there is an access path to the ob- same object. This can lead to information leakage. ject from the parameter reference h. On the other hand Given the pointer graph of a program, we compute for the object 2:foo.LinkedList created at 2: and the ob- each object the set of methods that directly access the ob- ject 6:bar.LinkedList created at 6: does not escape foo. ject. Let us call the resulting graph as method-annotated One simple way to compute whether an object O escapes a pointer graph (MAPG). It is straightforward to compute method M is first to construct the pointer graph and then check if there is a path to O in the graph that can be reached this information if we use fully qualified names for ref- 0 0 erences. Consider the pointer graph shown in Figure 4 by some node O that is accessed in some other method M and the life time of M 0 exceeds the life time of M. and the object 62:ObsId. The set of methods that ac- cess this object can be read off from the pointer graph, In role escape analysis we extend the method escape analysis as follows. An object O role escapes a method M which is Driver.main, Subject.addObs, Subject.notify, with role R if there is a path in the pointer graph from and ObsId.update. Since any of these methods have the “ca- 0 0 pability” to access the object, the object must be assigned some node O that is accessed in some other method M with role R0 and R 6 R0. Conversely, an object O is role a role that is the least upper bound of the roles assigned to 10 these methods. Now a principal who wants to access the confined to a M if O does not role escape M. The role escape analysis essentially consists of determining if a node object referenced by 62:ObsId must have a role that is at least equal to the least upper bound of the roles assigned to p in the pointer graph that is annotated with method m and role r ∈ Role+(m) is reachable from another node p0 that is the methods that access the object. Unfortunately, in J2EE 0 0 + 0 0 it is not possible to assign roles to objects or class instances annotated with m and role r ∈ Role (m ) and r 6 r . (also see Section 4). Notice that the converse of role escape, which is role con- finement, of an object is closely related to information flow 3.2 Role Escape Analysis security of Bell and LaPadula’s Multi-Level Security with In this section we introduce the concept of role escape 10Our definition of role escape is more general than the tradi- analysis inspired by method and thread escape analysis [7]. tional method or thread escape, where by we define method Escape analysis is a procedure for determining the set of lifetime as a role.
175
that gender, and ethnic have the same “consistency prop- erty”. A simple example of a consistency property is that the two fields are always accessed by the same set of meth- ods. Another example of a consistency property is access rights; if a user is permitted to access one of the two data fields, then the user is automatically allowed to access the other data field. Yet another example of a consistency prop- erty is encryption; the values of the two data fields must use the same encryption/decryption keys. Typically an applica- tion developer has a better understanding of the consistency properties than the application deployer. For instance, if gender, and ethnic are always accessed by the same set of methods, the developer can then define a simple consistency Figure 7: A typestate diagram for the File example. property classification called race. class Employee { Mandatory Access Control [5]. Since we model roles using a access(name, idy) String fname ; lattice structure, if an object O does not escape a role R then access(name, idy) String lname ; the object cannot leak information outside the role. Also, access(idy) int id ; if an object escapes a role, the object can become “tainted” access(idy) int ssn ; by an external principal with access to the object [19, 24] access(race) String gender ; access(race) String ethnic ; 4. CONSISTENCY-BASED SECURITY } It is often the case that an application developer has a Often a field (or a method) can belong to more than one better understanding of the application that he or she is class of a consistency property. For instance, fname and developing than an application deployer or the system ad- lname belong to two different classes of the access prop- ministrator. On the other hand an application deployer has erty. A consistency property consists of two parts: (1) a better understanding of the application deployment envi- a property name such as access and a set of classifica- ronment than an application developer. The key idea be- tions, such as name, idy, and race. Given the consistency hind consistency-based security (CBS) is to focus on the properties defined by an application developer, a natural consistency properties of data and methods. An application question to ask is how will the application deployer use developer simply identifies and defines the consistency prop- them. An application deployer first must query the ap- erties as code annotation. A simple consistency property plication for all application-defined properties. Next, the could be that two fields of a Java class are modified by the application deployer associate roles to consistency proper- same set of methods. Another consistency property is the ties. Supposing an application deployer defines two roles typestate property, which is often used to specify ordering called Manager and NonManager, and associates the Manager of methods in an application. In CBS, a tool can scan the role with access(name,idy,race) and NonManager role with code and present the developer’s consistency properties to access(name). With this association, a Manager can access an application deployer. An application deployer can then all the defined fields, whereas a NonManager can only access use the consistency properties as a guide for associating se- the fields fname and lname. Notice that a deployer does curity properties to roles, and then grant authorization to not need to understand how a developer defined the consis- users. tency properties. The deployer only has to know what set of consistency properties have been defined by the developer. 4.1 Data Consistency Security In this section we will illustrate a simple consistency prop- 4.2 Role Typestates erty in which two or more fields of an object are all accessed In this section we define RBAC by focusing on the type- by the same set of methods. Given this property, an ap- state consistency property. The approach that we advocate plication deployer can then associate the same role for all in this section is very simple: an application developer de- methods that access these fields. Consider a simple em- fines the typestate properties and an application deployer ployee record in a company. then assign roles based on the typestate properties. Types- tates provide much richer information than simple method enum EmpType = {RSM, Manager, SoftEng, Staff} ; interfaces to an application deployer. class Employee { Strom and Yemini introduced the concept of typestate as String fname ; // first name an extension to the notion of a type by requiring that a vari- String lname ; // last name ; able be in certain state before operations on the variables int id ; // company identity number can be performed [27]. In other words, certain precondi- int ssn ; // social security number tions must be met prior to performing any operation on a String gender ; variable. Typestate was originally introduced for tracking String ethnic ; // ethnicity certain kinds of flow-sensitive errors or bugs, such as unini- EmpType etype ; tialized variables. For object-oriented (OO) programs, the } typestate of an object (that is, an instance of a class) is a Supposing an application developer is developing a busi- description or a configuration of all its fields [8]. In OO pro- ness application, such as payroll application, and decides grams, a method that is invoked on an object o typically
176
Figure 8: (a) A hierarchical typestate diagram and (b) Role hierarchy assignment. has a partial view of the object o. One can use typestates to a specification, an application deployer can now associate define a consistent view of an object prior to an invocation security properties to typestates. For instance, an applica- of a method on the object. Consider a simple file object that tion deployer can associate Manager role to Start, Open and contains two typestates Open and Close. Close typestates, and Engineer role to Open. What this es- sentially means is that only a Manager is allowed to execute class File { all methods of the class, whereas an Engineer is allowed to typestate = {Start, Open, Close} execute only read() and write() methods. // @requires Start We partition a typestate diagram into a hierarchical File create(String fname) ; // create file structure and use the notion of hierarchical typestate dia- // @requires Close gram [16]. A hierarchical typestate diagram consists of a set void open() // of states and a set of transitions.A state can be composed of // @requires Open other states, called the sub-states. This enables modeling of String read() ; // returns the content of file complex hierarchical typestate diagram by abstracting away // @requires Open detailed behavior into multiple levels. States that do not void write(String data) ; // write to file contain sub-states are called simple states, whereas states // requires Open that have sub-states are called composite states. States may void close() ; // close the file be nested to any level. A transition relates two states: a } source state and a destination state. Transitions are labeled and each label corresponds to a method invocation. An A typestate diagram is a finite state diagram, with nodes invocation of a method can cause a state transition. The hi- denoting the typestates of a class and the labeled edges de- erarchical states in a typestate diagram induces a tree struc- noting transition between typestates of a class. The labels ture. Figure 8 illustrates a hierarchical typestate diagram in on the edges correspond to (a subset of) methods defined in which we have expanded the Open state shown in Figure 7. the class. The source and destination nodes of a transition For role typestates, it is natural to model roles using a correspond to pre- and post-conditions of the method that tree structure. This is illustrated in Figure 8(b). The def- labels the transition, respectively. An execution of a method inition of senior relation is simpler: r s if r is a parent takes an instance of a class from one typestate to another of s in the role hierarchy tree. We assign roles to hierar- typestate. Figure 7 illustrates a typestate diagram for the chical states in the typestate diagram. If s is assigned the File class. The typestate diagram specifies the life-cycle of role r then the P er(r) = {t|t ∈ Root(s)}, where Root(s) how an instance of the File class goes between Open and is a set of all states in the sub-tree that is rooted at s in Close typestates. A method, such as open(), is executed the typestate hierarchy tree. Consider the role assignment only when its pre-condition typestate of the File object is shown Figure 8(b), and the permission set for each roles Close, and after the execution the new typestate of the ob- are P er(R0) = {File, Open, Close, OpenRead, OpenWrite}, ject is Open. Both read() and write() methods can execute P er(R1) = {Open, OpenRead, OpenWrite}, P er(R2) = only when the File object is in Open state. {Close}, P er(R3) = {OpenRead}, and P er(R4) = The typestate diagram is an external specification of a {OpenWrite}. Once again, consider the role assignment class. It prescribes the order in which a client can invoke shown in Figure 8(b). If a principal p is assigned the role R1 various methods defined in the class. Only an application then p can invoke both read and write, but cannot invoke developer understands the lifecycle of an object. Given such
177
close. Now if p is assigned R3 then p can only invoke the focus on detecting access-control inconsistencies when two read method. or more J2EE methods accessing the same data in the same Now consider a method such as File.close() and a prin- mode (either read or write) but are assigned with different cipal p who is assigned the role R1. The principal p should roles. They also do not discuss the concept of role escape not be allowed to invoke File.close() even if the current analysis and role typestates. Our consistency-based security typestate of the object referenced by the principal is Open. and role typestate is a way to extend J2EE model to deal This is because, the method File.close() creates a state with data-centric security. transition from Open to Close and p is not allowed to be Java 2 Standard Edition (J2SE) provides security mech- in state Close. So only principals with role File are es- anisms for protecting resources (e.g., file system) in terms sentially allowed to execute File.close(). Given a set of of run-time stack inspection. The security access control roles assigned to typestates, we can easily compute the roles model is based on properties that includes code origin and needed for methods—it is simply the least common ancestor principal’s execution environment. Banerjee and Naumann of the roles assigned to pre- and post-state of the method. give static analysis techniques for characterizing safe expres- Notice that when a File object is passed around to different sions, that is, expressions that never cause security viola- methods that are accessed by different principals, we only tions. Banerjee and Naumann have presented several re- have to ensure that roles are consistent on the current type- sults in a series of papers on access control and information state of the object and not have to worry about the methods flow control [2, 3, 4]. They approach the problem using themselves. language techniques, such as type theory, to detect security Typestates are a useful formalism for modeling access pat- violations and safety violations. We follow program analysis terns, including message patterns in Web Services. Once techniques for RBAC and also use typestate properties for such message patterns are modeled using typestates, we can RBAC. We also introduce the notion of role escape analysis assign roles to states using our approach. We are currently and the notion of role typestates to model and detect secu- exploring this line of research in Web Service security. rity problems in J2EE. Recently Pistoia et al presented an interprocedural analysis to detect portions of trusted Java 5. DISCUSSION AND RELATED WORK code should be made privileged, and also to ensure that there are no tainted variables in privileged code [24]. The main focus of this paper is to address the challenges Park and Goldberg introduced the term escape analysis of role assignment and role semantics as it is currently used in the context of functional program analysis for statically in building J2EE applications. The current method-based determining parts of a list that are passed to a function do access control is limiting in terms of its expressive power. not escape the function call, and hence can be allocated on We believe that some form of data-centric security should stack [23]. Recently there have been several work on escape complement the method-based security. analysis in the context of Java [7, 6, 12]. Escape analysis Ferraiolo and Kuhn [9] introduced the notion role-based techniques have been applied both for allocating objects on access control for managing and controlling access to sensi- the call stack and for eliminating synchronization in multi- tive resource. Since then RBAC model has become popular threaded programs. Our work on role escape analysis gener- because of its generality in expressing a diverse set of access alizes the traditional escape analysis, where we can consider control policies [26, 22]. Li and Tripunitara propose security method and thread lifetime to be an instance of roles. Role analysis techniques for ensuring that security properties are escape analysis is useful for detecting confinement proper- correctly maintained even in the presence of delegating ad- ties of objects, and for detecting information leaks through ministrative privileges [18]. Their approach is not directly objects [11]. related to J2EE RBAC model, although their approach can Role typestates combines the notion of roles and types- be used to detect some of the access control problems with tates. The original work on typestate focused on finding delegation in the J2EE model. flow-sensitive errors [27]. DeLine and Fahndrich extended Pistoia et al. presents static analysis techniques for iden- the classical typestate theory to objects [8]. They use pre- tifying inconsistent security role assignment in J2EE appli- and post-conditions to express allowed transition rules be- cations [25]. Pistoia et al. model roles as logical expressions tween the typestates of the object, and typestates to express rather than as set of method, and these logical expression predicates (or constraints) over the objects concrete state, can get very complex. We use a simpler lattice structure for which includes the field states. Now by associating roles modeling roles. Pistoia et al. also use a more precise con- to typestates we define a more general model for specify- text sensitive analysis for tracking logical expressions and ing roles—instead of specifying roles on methods, we now also deal with role delegation semantics of J2EE model. To specify them on typestates. simplify the presentation we chose to ignore role delegation, which in J2EE is ambiguous. Pistoia et al. approach models the method-based role assignment, and does not deal with data flow aspect of RBAC. In our paper we introduce the no- 6. CONCLUSIONS tion of role escape analysis to specially address the need for In this paper we brought out some of the security issues data-centric security. We also presented consistency-based related to J2EE RBAC model. We illustrated several exam- security, along with role typestates for specifying access con- ples that show the limitation of method-based role assign- trol security. ment. We then discussed the concepts that bring out data- The role analysis described in this paper is also related to centric security model. We believe consistency based se- static analysis described by Naumovich and Centonze [20]. curity, that includes typestate security, should complement They also rightfully recognize the need for extending J2EE method-based security. Our next step is to define and ex- RBAC to explicitly deal with data fields, but do not give tend data centric security in the context of web applications, any solution for how to extend the model. Instead they including web services [11].
178
Acknowledgement [14] David Grove and Craig Chambers. A framework for I wish thank Larry Koved, Samuel Weber, and Xiaolan call graph construction algorithms. ACM Trans. Zhang for commenting on the earlier drafts of the paper. Program. Lang. Syst., 23(6):685–746, November 2001. [15] Michael Hind. Pointer analysis: haven’t we solved this 7. REFERENCES problem yet? In PASTE ’01: Proceedings of the 2001 [1] Eric Armstrong, Jennifer Ball, Stephanie Bodoff, ACM SIGPLAN-SIGSOFT workshop on Program Debbie Bode Carson, Ian Evans, Dale Green, Kim analysis for software tools and engineering, pages Haase, and Eric Jendrock. The J2EE 1.4 Tutorial . 54–61, New York, NY, USA, 2001. ACM Press. Sun Java System Application Server Platform Edition [16] Patrick Lam, Viktor Kuncak, and Martin Rinard. , 2005. Generalized typestate checking using set interfaces and [2] Anindya Banerjee and David A. Naumann. pluggable analyses. SIGPLAN Not., 39(3):46–55, 2004. Representation independence, confinement and access [17] Brian A. LaMacchia, Sebastian Lange, Matthew control [extended abstract]. In POPL ’02: Proceedings Lyons, Rudi Martin, and Kevin T. Price. .NET of the 29th ACM SIGPLAN-SIGACT symposium on Framework Security . Pearson Education, 2002. Principles of programming languages, pages 166–177, [18] Ninghui Li and Mahesh V. Tripunitara. Security New York, NY, USA, 2002. ACM Press. analysis in role-based access control. In SACMAT ’04: [3] Anindya Banerjee and David A. Naumann. Secure Proceedings of the ninth ACM symposium on Access information flow and pointer confinement in a control models and technologies, pages 126–135, New java-like language. In CSFW ’02: Proceedings of the York, NY, USA, 2004. ACM Press. 15th IEEE Computer Security Foundations Workshop [19] V. Benjamin Livshits and Monica S. Lam. Finding (CSFW’02), page 253, Washington, DC, USA, 2002. security vulnerabilities in java applications with static IEEE Computer Society. analysis. In Proceedings of the 14th USENIX Security [4] Anindya Banerjee and David A. Naumann. Symposium, 2005. Stack-based access control and secure information [20] Gleb Naumovich and Paolina Centonze. Static flow. J. Funct. Program., 15(2):131–177, 2005. Analysis of Role-Based Access Control in J2EE [5] D. E. Bell and L. J. LaPadula. Secure computer Applications. In Workshop on testing, analysis and system: unified exposition and multics interpretation. verification of web services, pages 1–10, New York, Technical Report MTR-2997, MITRE Corporation, NY, USA, 2004. ACM Press. March 1976. [21] Flemming Nielson, Hanne R. Nielson, and Chris [6] Bruno Blanchet. Escape analysis for object-oriented Hankin. Principles of Program Analysis. languages: application to java. In OOPSLA ’99: Springer-Verlag New York, Inc., Secaucus, NJ, USA, Proceedings of the 14th ACM SIGPLAN conference on 1999. Object-oriented programming, systems, languages, and [22] S. L. Osborn, R. Sandhu, and Q. Munawer. applications, pages 20–34, New York, NY, USA, 1999. Configuring role-based access control to enforce ACM Press. mandatory and discretionary access control policies. [7] J.-D. Choi, M. Gupta, M. Serrano, V. C. Sreedhar, ACM Transactions on Information and System and S. Midkiff. Escape analysis for Java. In Security, 3(2), February 2000. Proceedings of ACM SIGPLAN Conference on [23] Young Gil Park and Benjamin Goldberg. Escape Object-Oriented Programming Systems, Languages, analysis on lists. In PLDI ’92: Proceedings of the and Applications, Denver, Colorado, November 1999. ACM SIGPLAN 1992 conference on Programming [8] R. DeLine and M. Fahndrich. Typestates for objects. language design and implementation, pages 116–127, In 18th European Conference on Object-Oriented New York, NY, USA, 1992. ACM Press. Programming, 2004. [24] Marco Pistoia, Robert J. Flynn, Larry Koved, and [9] David F. Ferraiolo and D. Richard Kuhn. Role-based Vugranam C. Sreedhar. Interprocedural analysis for access controls. In 15th NIST-NCSC National privileged code placement and tainted variable Computer Security Conference, pages 554–563, detection. In 19th European Conference on Baltimore, MD, USA, October 1992. Object-Oriented Programming, pages 362–386, 2005. [10] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, [25] Marco Pistoia, Vugranam Sreedhar, and Robert D. Richard Kuhn, and Ramaswamy Chandramouli. Flynn. Static evaluation of role-based access control Proposed nist standard for role-based access control. policies in distributed component-based systems. ACM Trans. Inf. Syst. Secur., 4(3):224–274, 2001. Technical Report RC23836 (W0411-166), IBM TJ [11] Elena Ferrari and Bhavani Thuraisingam. Web and Watson Research Center, IBM Research Division, Information Security. Idea Group Publishing, 2006. Yorktown, NY, November 2004. [12] FredericVivien and Martin Rinard. Incrementalized [26] Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein, pointer and escape analysis. In PLDI ’01: Proceedings and Charles E. Youman. Role-based access control of the ACM SIGPLAN 2001 conference on models. IEEE Computer, 29(2):38–47, 1996. Programming language design and implementation, [27] R. Strom and S. Yemini. Typestate: a programming pages 35–46, New York, NY, USA, 2001. ACM Press. language concept for enhancing software reliability. [13] Erich Gamma, Richard Helm, Ralph Johnson, and IEEE Transactions on Software Engineering, 12(1), John Vlissides. Design Patterns: Elements od Jan 1986. Reusable Object-Oriented Software. Addison-Wesley Publishing Company, New York, NY, 1995.
179