International Conference on Software Engineering Minneapolis MN

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

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 securitysensitive 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 set. Grades Permission to invoke method assign. Homework Professor User bob User alice 2

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 Student. Bean Remote set. Grade 3

RBAC Programming and Configuration Challenges Redundant Roles Granted: Student, Assistant User: bob Intercomponent call Intracomponent call m 0 Component Role Required: Student or Assistant run-as: Professor m 1 Role Required: Professor m 3 Subversive m 6 Role Required: Student m 2 m 4 m 7 Insufficient m 5 Role Required: Professor Insufficient Role Required: Student 4

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 5

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 υ(bob) = Student Ù Assistant Roles Granted: Student, Assistant User: bob Intercomponent call μ(m 0) = Student Intracomponent call m 0 Component μ(m 1) = Student Ú Assistant π(m 1) = π(m 4) = Professor Role Required: Student or Assistant run-as: Professor μ(m 3) = Professor Role Required: Professor m 3 m 6 μ(m 6) = Student Role Required: Student m 1 Role Required: Student m 2 μ(m 5) = Professor m 4 m 7 m 5 Role Required: Professor μ(m 7) = Student Role Required: Student 6

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 7

Concrete Instrumented Semantics Init – User u calls entry point m' Call – Method m calls method m' Return – Method m' returns to method m S 1 ε υ(bob) = Student Ù Assistant ⇒ μ(m 0) = Student S 2 υ(bob) = Student Ù Assistant ⇒ μ(m 1) = Student Ú Assistant S 3 5 υ(bob) = Student Ù Assistant p(m 1) = Professor ⇒ μ(m 3) = Professor μ(m 4) Æ S 4 6 p(m 1) = Professor υ(bob) = Student Ù Assistant Roles Granted: Student, Assistant User: bob Intercomponent call μ(m 0) = Student Intracomponent call m 0 Component μ(m 1) = Student Ú Assistant π(m 1) = π(m 4) = Professor Role Required: Student or Assistant run-as: Professor μ(m 3) = Professor Role Required: Professor m 3 Role Required: Student m 1 m 4 8

Modified Instrumentation Init – User u calls entry point m' Intercomponent Call – m calls m', md(m) ≠ md(m') Intracomponent m' returns to m', md(m) Return – Method Call – m callsmethod m = md(m') S 1 S 2 υ(bob) = Student Ù Assistant S 3 5 υ(bob) = Student Ù Assistant S 6 υ(bob) = Student Ù Assistant ε υ(bob) = Student Ù Assistant Roles Granted: Student, Assistant User: bob Intercomponent call μ(m 0) = Student Intracomponent call m 0 Component μ(m 1) = Student Ú Assistant π(m 1) = π(m 4) = Professor Role Required: Student or Assistant run-as: Professor μ(m 3) = Professor Role Required: Professor m 3 Role Required: Student m 1 m 4 9

Concrete Instrumented Semantics Init – User u calls entry point m' Call – Method m calls method m' Return – Method m' returns to method m S 1 ε υ(bob) = Student Ù Assistant ⇒ μ(m 0) = Student S 2 υ(bob) = Student Ù Assistant ⇒ μ(m 1) = Student Ú Assistant S 3 5 υ(bob) = Student Ù Assistant p(m 1) = Professor ⇒ μ(m 3) = Professor μ(m 4) Æ S 4 6 p(m 1) = Professor υ(bob) = Student Ù Assistant Roles Granted: Student, Assistant User: bob Intercomponent call μ(m 0) = Student Intracomponent call m 0 Component μ(m 1) = Student Ú Assistant π(m 1) = π(m 4) = Professor Role Required: Student or Assistant run-as: Professor μ(m 3) = Professor Role Required: Professor m 3 Role Required: Student m 1 m 4 10

Modified Instrumentation Init – User u calls entry point m' Intercomponent Call – m calls m', md(m) ≠ md(m') Intracomponent m' returns to m', md(m) Return – Method Call – m callsmethod m = md(m') S 1 S 2 υ(bob) = Student Ù Assistant S 3 5 υ(bob) = Student Ù Assistant S 6 υ(bob) = Student Ù Assistant ε υ(bob) = Student Ù Assistant Roles Granted: Student, Assistant User: bob Intercomponent call μ(m 0) = Student Intracomponent call m 0 Component μ(m 1) = Student Ú Assistant π(m 1) = π(m 4) = Professor Role Required: Student or Assistant run-as: Professor μ(m 3) = Professor Role Required: Professor m 3 Role Required: Student m 1 m 4 11

Sufficiency • An RBAC policy P for a program p is sufficient if for any user u and for any execution e such that υ(u) ⇒ μ(me), e does not transition to an authorization error state; insufficient otherwise • Insufficient policies can lead to stability problems Roles Granted: Student User: bob Intercomponent call Intracomponent call m 0 Component Role Required: Student or Assistant run-as: Professor m 1 Role Required: Professor m 3 m 6 Role Required: Student m 2 m 4 m 7 Insufficient m 5 Role Required: Professor Insufficient Role Required: Student 12

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 Redundant Roles Granted: Student, Assistant User: bob Intercomponent call Intracomponent call m 0 Component Role Required: Student or Assistant run-as: Professor m 1 m 3 m 6 Role Required: Student m 2 m 4 m 5 m 7 13

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 User: bob Intercomponent call Intracomponent call m 0 Component Role Required: Student or Assistant run-as: Professor m 1 Role Required: Professor m 3 Subversive m 6 Role Required: Student m 2 m 4 m 5 m 7 14

Analysis Domain r 1 (r 1 r 5) (r 2 r 3) r 1 (r 1 r 5) (r 2 r 3) r 2, r 3 r 1 r 5 r 4 r 1 r 5 r 1, r 5 r 4 • μ : 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 15

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

Role-Requirement Analysis υ(bob) = Student Ù Assistant Subversion Minimality Sufficiency Analysis • Repeat analysis disregarding distinction between υ(u), Iteratively abstractly sufficient if Policy P isremove one role from role assignmentsinter- and intra-component)edges 0) ∀u∈U, and π(m), ∀m∈M, and verify whether the – υ(u) ⇒ In(e 0 ∪ Gen(n " entry edge e 0 = (n, resulting RBAC policy is 0), " uabstractly sufficient • Soundness Theorem: n still ∈ U : υ(u) ⇒ μ(n 0) – π(n 1) ⇒ In(e) ∪ sufficient, run-as not e = (n 1, n 2 • Completeness Theorem 2), "then it isedge subversive) – If P is abstractly Gen(n • Soundness Theorem: P is abstractly sufficient, and $ abstractly – If an RBAC policy Potential false positives – – User: bob Student sufficient policy Q : Q ⇒P, then P is redundant P abstractly sufficient ≺ P sufficient negatives Potential false positives m 0 Student, Assistant μ(m 0) = Student Professor μ(m 1) = Student Ú Assistant π(m 1) = π(m 4) = Professor Student μ(m 6) = Student m 6 m 2 Professor m 3 Student m 1 Professor μ(m 3) = Professor m 4 μ(m 5) = Professor Student m 7 μ(m 7) = Student 17 m 5

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 • http: //wala. sourceforge. net 18

Modeling Remote Method Invocations ENTERPRISE BEAN Bean 1 Bean SOURCE CODE public void m 1() { Context initial = new Initial. Context(); Object obj. Ref = initial. lookup("java: comp/env/ejb/Bean 2"); Bean 2 Home bean 2 Home = (Bean 2 Home) Portable. Remote. Object. narrow(objref , Bean 2 Home. class); Bean 2 bean 2 Object = bean 2 Home. create(); bean 2 Object. m 2(); } Traditional Static Analysis Engine ESPE ENTERPRISE BEAN DEPLOYMENT DESCRIPTOR Bean 1 Bean. m 1() Bean 2. m 2() Bean 2 Bean. m 2() Bean 1 Bean Bean 1 Home Bean 1 Bean 1 Bean Stateless Bean 1 ejb/Bean 2 Session Bean 2 Home Bean 2 Bean 2 Bean 19

ESPE Experimental Results 20

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 21

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 22

Thank You!