When Role Models Have Flaws: Static Validation of Enterprise Security Policies Marco Pistoia IBM T. J. Watson Research Center Hawthorne, New York Stephen J. Fink IBM T. J. Watson Research Center Hawthorne, New York Robert J. Flynn Polytechnic University Brooklyn, New York Eran Yahav IBM T. J. Watson Research Center Hawthorne, New York International Conference on Software Engineering – Minneapolis, MN, May 2007

2 Role-Based Access Control Systems A role is a set of permissions that can be granted to users and/or groups of a computer system Each permission represents the right to perform a security- sensitive operation; it does not directly represent the right to access security-sensitive data or resources Examples of RBAC systems: –Java, Enterprise Edition (Java EE) –Microsoft.NET Common Language Runtime (CLR) Permission to invoke method setGrades Permission to invoke method assignHomework Professor User bob User alice

3 Role Definition in Java EE Roles are application-specific They are defined in the deployment descriptors of an application’s components They can be used to restrict access to enterprise methods Professor Professor StudentBean Remote setGrade Professor Professor StudentBean Remote setGrade

4 RBAC Programming and Configuration Challenges Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call Subversive Insufficient Redundant m0 m1 m2 m3 m4 m5 m6 m7 Role Required: Student Insufficient User: bob

5 Contributions Novel theoretical foundation to model the flow of authorization information in an RBAC system Enterprise Security Policy Evaluator (EPSE), an interprocedural analysis framework for RBAC –Analysis implementation –Static analyzer tailored to Java, EE applications Identification of RBAC policies that are: –Insufficient –Redundant –Subversive

6 RBAC Policies Given a program with sets of methods M, roles R, and users U, role formulae B(R) are propositional logic statements over R, where each r  R is considered as a predicate An RBAC policy is a tuple P = (R, U, υ, μ, π), where: –υ : U → B(R) is the user role assignment function (conjunction of roles) –μ : M → B(R) is the role requirement function (disjunction of roles) –π : M z B(R) is the principal delegation partial function Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call m0 m1 m2 m3 m4 m5 m6 m7 Role Required: Student User: bob υ( bob ) = Student  Assistant μ( m1 ) = Student  Assistant π( m1 ) = π( m4 ) = Professor μ( m6 ) = Student μ( m7 ) = Student μ( m5 ) = Professor μ( m0 ) = Student μ( m3 ) = Professor

7 Concrete Semantics Standard concrete semantics for a program in the underlying language State S = (pc, stack, heap, local_variables, global_variables) Instrumented program state –Additional stack w of dynamically held roles –Stack alphabet Σ := B(R)  transition of instrumented concrete semantics from configuration to configuration Operations that affect instrumentations are only method calls and returns

8 Concrete Instrumented Semantics Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call m0 m1 m3 m4 User: bob υ( bob ) = Student  Assistant μ( m1 ) = Student  Assistant π( m1 ) = π( m4 ) = Professor μ( m0 ) = Student μ( m3 ) = Professor Init – User u calls entry point m' υ( bob ) = Student  Assistant ⇒ μ( m0 ) = Student Call – Method m calls method m' S1S1 S1S1 Return – Method m' returns to method m ε ε S2S2 S2S2 υ( bob ) = Student  Assistant S3S3 S3S3 υ( bob ) = Student  Assistant ⇒ μ( m1 ) = Student  Assistant S5S5 S5S5 υ( bob ) = Student  Assistant  ( m1 ) = Professor ⇒ μ( m3 ) = Professor S4S4 S4S4  ( m1 ) = Professor S6S6 S6S6  ( m1 ) = Professor ⇒ μ( m4 ) = 

9 Modified Instrumentation Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call m0 m1 m3 m4 User: bob υ( bob ) = Student  Assistant μ( m1 ) = Student  Assistant π( m1 ) = π( m4 ) = Professor μ( m0 ) = Student μ( m3 ) = Professor Init – User u calls entry point m' Intercomponent Call – m calls m', md(m) ≠ md(m') S1S1 S1S1 Return – Method m' returns to method m ε ε S2S2 S2S2 υ( bob ) = Student  Assistant S3S3 S3S3 S5S5 S5S5 S6S6 S6S6 Intracomponent Call – m calls m', md(m) = md(m')

10 Concrete Instrumented Semantics Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call m0 m1 m3 m4 User: bob υ( bob ) = Student  Assistant μ( m1 ) = Student  Assistant π( m1 ) = π( m4 ) = Professor μ( m0 ) = Student μ( m3 ) = Professor Init – User u calls entry point m' υ( bob ) = Student  Assistant ⇒ μ( m0 ) = Student Call – Method m calls method m' S1S1 S1S1 Return – Method m' returns to method m ε ε S2S2 S2S2 υ( bob ) = Student  Assistant S3S3 S3S3 υ( bob ) = Student  Assistant ⇒ μ( m1 ) = Student  Assistant S5S5 S5S5 υ( bob ) = Student  Assistant  ( m1 ) = Professor ⇒ μ( m3 ) = Professor S4S4 S4S4  ( m1 ) = Professor S6S6 S6S6  ( m1 ) = Professor ⇒ μ( m4 ) = 

11 Modified Instrumentation Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call m0 m1 m3 m4 User: bob υ( bob ) = Student  Assistant μ( m1 ) = Student  Assistant π( m1 ) = π( m4 ) = Professor μ( m0 ) = Student μ( m3 ) = Professor Init – User u calls entry point m' Intercomponent Call – m calls m', md(m) ≠ md(m') S1S1 S1S1 Return – Method m' returns to method m ε ε S2S2 S2S2 υ( bob ) = Student  Assistant S3S3 S3S3 S5S5 S5S5 S6S6 S6S6 Intracomponent Call – m calls m', md(m) = md(m')

12 Sufficiency An RBAC policy P for a program p is sufficient if for any user u and for any execution e such that υ(u) ⇒ μ(m e ), e does not transition to an authorization error state; insufficient otherwise Insufficient policies can lead to stability problems Roles Granted: Student Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call Insufficient m0 m1 m2 m3 m4 m5 m6 m7 Role Required: Student Insufficient User: bob

13 Minimality An RBAC policy P sufficient for a program p is minimal if there exists no sufficient RBAC policy Q for p such that Q ≺ P Otherwise, P is redundant Redundant policies violate the Principle of Least Privilege Roles Granted: Student, Assistant Role Required: Student or Assistant run-as: Professor Component Intercomponent call Intracomponent call Redundant m0 m1 m2 m3 m4 m5 m6 m7 Role Required: Student User: bob

14 Subversion An RBAC policy P is subversive if there exists any execution with P that transitions to an authorization error state under the base instrumentation, but not under the modified instrumentation Subversive policies violate the Principle of Least Privilege Roles Granted: Student Role Required: Student or Assistant run-as: Professor Role Required: Professor Component Intercomponent call Intracomponent call Subversive m0 m1 m2 m3 m4 m5 m6 m7 Role Required: Student User: bob

15 Analysis Domain r1r1 r1r1 r2,r3r2,r3 r2,r3r2,r3 r4r4 r4r4 r1,r5r1,r5 r1,r5r1,r5 r1r1 r1r1 r2,r3r2,r3 r2,r3r2,r3 r4r4 r4r4 r1,r5r1,r5 r1,r5r1,r5 r1  r5r1  r5 (r 1  r 5 )  (r 2  r 3 ) r1  r5r1  r5 r1  r5r1  r5 r1  r5r1  r5 r 1  (r 1  r 5 )  (r 2  r 3 ) μ : M → B(R) maps each method to a disjunction of roles Our analysis computes conjunctions of disjunctions The analysis domain can be the set MCNF(R): role formulae in Monotone (no negation) Conjunctive Normal Form

16 Analysis Domain Theorem: (MCNF(R), ∧, ⇒ ) ≈ ( P ( P (R)), ∪, ⊇ ) Corollary: Set-based dataflow analysis formulation is a correct representation 

17 Role-Requirement Analysis m0 m1 m2 m3 m4 m5 m6 m7 User: bob υ( bob ) = Student  Assistant μ( m1 ) = Student  Assistant π( m1 ) = π( m4 ) = Professor μ( m6 ) = Student μ( m7 ) = Student μ( m5 ) = Professor μ( m0 ) = Student μ( m3 ) = Professor Student Professor Student  Assistant Professor Student Student  Assistant Professor Student Professor Sufficiency Analysis Policy P is abstractly sufficient if –υ(u) ⇒ In(e 0 ) ∪ Gen(n 0 )  entry edge e 0 = (n, n 0 ),  u ∈ U : υ(u) ⇒ μ(n 0 ) –π(n 1 ) ⇒ In(e) ∪ Gen(n 2 ),  run-as edge e = (n 1, n 2 ) Soundness Theorem: –P abstractly sufficient ⇒ P sufficient –Potential false positives Minimality Analysis Iteratively remove one role from role assignments υ(u), ∀ u ∈ U, and π(m), ∀ m ∈ M, and verify whether the resulting RBAC policy is still abstractly sufficient Completeness Theorem –If an RBAC policy P is abstractly sufficient, and  abstractly sufficient policy Q : Q ≺ P, then P is redundant –Potential false negatives Subversion Analysis Repeat analysis disregarding distinction between inter- and intra-component edges Soundness Theorem: –If P is abstractly sufficient, then it is not subversive –Potential false positives

18 Implementation ESPE is based on T. J. Watson Libraries for Analysis (WALA), specifically tailored to Java, EE applications WALA analyzes enterprise beans after deployment configuration, but before deployment –Less code  Scalability –No analysis of container implementation  Precision –No dependence on container vendor  Portability WALA models several native methods WALA models reflection by tracking objects to casts

19 Modeling Remote Method Invocations Bean1Bean.m1() Bean2.m2() Traditional Static Analysis Engine Bean1Bean.m1() Bean2.m2() Bean2Bean.m2() ESPE ENTERPRISE BEAN Bean1Bean SOURCE CODE public void m1() { Context initial = new InitialContext(); Object objRef = initial.lookup("java:comp/env/ejb/Bean2"); Bean2Home bean2Home = (Bean2Home) PortableRemoteObject.narrow(objref, Bean2Home.class); Bean2 bean2Object = bean2Home.create(); bean2Object.m2(); } ENTERPRISE BEAN Bean1Bean SOURCE CODE public void m1() { Context initial = new InitialContext(); Object objRef = initial.lookup("java:comp/env/ejb/Bean2"); Bean2Home bean2Home = (Bean2Home) PortableRemoteObject.narrow(objref, Bean2Home.class); Bean2 bean2Object = bean2Home.create(); bean2Object.m2(); } ENTERPRISE BEAN DEPLOYMENT DESCRIPTOR Bean1Bean Bean1Home Bean1 Bean1Bean Stateless Bean1 ejb/Bean2 Session Bean2Home Bean2 Bean2Bean ENTERPRISE BEAN DEPLOYMENT DESCRIPTOR Bean1Bean Bean1Home Bean1 Bean1Bean Stateless Bean1 ejb/Bean2 Session Bean2Home Bean2 Bean2Bean

20 ESPE Experimental Results

21 Discussion Closed-world analysis Call-graph construction algorithm used: RTA All Java SE and Java EE libraries included in the analysis scope No false positives detected: –Java EE applications trigger the execution of libraries, but they themselves are shallow –Calling patterns in Java EE programs that affect RBAC analysis are predominantly monomorphic –Most enterprise beans map directly from the structure of an underlying relational database, and so do not utilize inheritance or linked structures –Applications rarely store or manipulate EJB instances with complex heap data structures –Although the underlying container utilizes complex libraries and data structures, the WALA analyzer truncates paths into the container, so container code does not pollute the application-level call graph –Interactions with Java standard libraries are usually uninteresting for role analysis, since library methods are not restricted with roles

22 Conclusion 1.Defined theoretical foundation for RBAC consistency and policy validations 2.Introduced and implemented static analysis models 3.Static analyzer tailored to Java EE applications 4.Experimental results have shown zero false positives

Thank You!