When Role Models Have Flaws: Static Validation of Enterprise Security Policies

1. International Conference on Software Engineering – Minneapolis, MN, May 2007 When Role Models Have Flaws:Static Validationof Enterprise Security Policies Marco PistoiaIBM T. J. Watson Research CenterHawthorne, New Yorkpistoia@us.ibm.com Stephen J. FinkIBM T. J. Watson Research CenterHawthorne, New Yorksjfink@us.ibm.com Robert J. FlynnPolytechnic UniversityBrooklyn, New Yorkflynn@poly.edu Eran YahavIBM T. J. Watson Research CenterHawthorne, New Yorkeyahav@us.ibm.com

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) User bob Permission to invokemethod setGrades Permission to invokemethod assignHomework User alice Professor

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 <assembly-descriptor> <security-role> <role-name>Professor</role-name> </security-role> <method-permission> <role-name>Professor</role-name> <method> <ejb-name>StudentBean</ejb-name> <method-intf>Remote</method-intf> <method-name>setGrade</method-name> </method> </method-permission> </assembly-descriptor>

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

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 formulaeB(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) • π : MzB(R) is the principal delegation partial function Roles Granted:Student, Assistant υ(bob) = StudentÙ Assistant User: bob Intercomponent call μ(m0) = Student Intracomponent call m0 Role Required: Student Component μ(m1) = StudentÚAssistant Role Required: Student or Assistant run-as: Professor m1 m2 μ(m5) = Professor π(m1) = π(m4) = Professor Role Required: Professor m3 m4 m5 μ(m3) = Professor Role Required: Professor m6 m7 μ(m7) = Student μ(m6) = Student Role Required: Student Role Required: Student

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) • <S, w>  <S', w' > transition of instrumented concrete semantics from configuration <S, w> to configuration <S', w' > • Operations that affect instrumentations are only method calls and returns

8. Concrete Instrumented Semantics <S,w> Init – User u calls entry point m' Call – Method m calls method m' Return – Method m' returns to method m S1 ε υ(bob) = StudentÙ Assistant ⇒ μ(m0) = Student S2 υ(bob) = StudentÙ Assistant υ(bob) = StudentÙ Assistant ⇒ μ(m1) = Student Ú Assistant S5 S3 υ(bob) = StudentÙ Assistant p(m1) = Professor ⇒ μ(m3) = Professor p(m1) = Professor ⇒ μ(m4) = Æ S6 S4 p(m1) = Professor p(m1) = Professor Roles Granted:Student, Assistant υ(bob) = StudentÙ Assistant User: bob Intercomponent call μ(m0) = Student Intracomponent call m0 Role Required: Student Component μ(m1) = StudentÚAssistant Role Required: Student or Assistant run-as: Professor m1 π(m1) = π(m4) = Professor m3 m4 μ(m3) = Professor Role Required: Professor

9. Return – Method m' returns to method m Modified Instrumentation Init – User u calls entry point m' Intercomponent Call – m calls m', md(m) ≠ md(m') Intracomponent Call – m calls m', md(m) = md(m') S1 ε S2 υ(bob) = StudentÙ Assistant S3 S5 υ(bob) = StudentÙ Assistant S6 υ(bob) = StudentÙ Assistant Roles Granted:Student, Assistant υ(bob) = StudentÙ Assistant User: bob Intercomponent call μ(m0) = Student Intracomponent call m0 Role Required: Student Component μ(m1) = StudentÚAssistant Role Required: Student or Assistant run-as: Professor m1 π(m1) = π(m4) = Professor m3 m4 μ(m3) = Professor Role Required: Professor

10. Concrete Instrumented Semantics <S,w> Init – User u calls entry point m' Call – Method m calls method m' Return – Method m' returns to method m S1 ε υ(bob) = StudentÙ Assistant ⇒ μ(m0) = Student S2 υ(bob) = StudentÙ Assistant υ(bob) = StudentÙ Assistant ⇒ μ(m1) = Student Ú Assistant S5 S3 υ(bob) = StudentÙ Assistant p(m1) = Professor ⇒ μ(m3) = Professor p(m1) = Professor ⇒ μ(m4) = Æ S6 S4 p(m1) = Professor p(m1) = Professor Roles Granted:Student, Assistant υ(bob) = StudentÙ Assistant User: bob Intercomponent call μ(m0) = Student Intracomponent call m0 Role Required: Student Component μ(m1) = StudentÚAssistant Role Required: Student or Assistant run-as: Professor m1 π(m1) = π(m4) = Professor m3 m4 μ(m3) = Professor Role Required: Professor

11. Return – Method m' returns to method m Modified Instrumentation Init – User u calls entry point m' Intercomponent Call – m calls m', md(m) ≠ md(m') Intracomponent Call – m calls m', md(m) = md(m') S1 ε S2 υ(bob) = StudentÙ Assistant S3 S5 υ(bob) = StudentÙ Assistant S6 υ(bob) = StudentÙ Assistant Roles Granted:Student, Assistant υ(bob) = StudentÙ Assistant User: bob Intercomponent call μ(m0) = Student Intracomponent call m0 Role Required: Student Component μ(m1) = StudentÚAssistant Role Required: Student or Assistant run-as: Professor m1 π(m1) = π(m4) = Professor m3 m4 μ(m3) = Professor Role Required: Professor

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) ⇒ μ(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 m0 Role Required: Student Component Role Required: Student or Assistant run-as: Professor m1 m2 Insufficient Role Required: Professor m3 m4 m5 Role Required: Professor Insufficient m6 m7 Role Required: Student Role Required: Student

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 User: bob Redundant Intercomponent call Intracomponent call m0 Role Required: Student Component Role Required: Student or Assistant run-as: Professor m1 m2 m3 m4 m5 m6 m7 Role Required: Student

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 User: bob Intercomponent call Intracomponent call m0 Role Required: Student Component Role Required: Student or Assistant run-as: Professor m1 m2 m3 m4 m5 Role Required: Professor Subversive m6 m7 Role Required: Student

15. μ : 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 Analysis Domain r1 (r1r5) (r2r3) r1 r1 (r1r5) (r2r3) r2,r3 r2,r3 r1r5 r1r5 r1r5 r4 r4 r1r5 r1,r5 r1,r5

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

17. Role-Requirement Analysis User: bob υ(bob) = StudentÙ Assistant Sufficiency Analysis • Policy P is abstractly sufficient if • υ(u) ⇒ In(e0) ∪ Gen(n0)"entry edge e0 = (n, n0), "u ∈ U : υ(u) ⇒ μ(n0) • π(n1) ⇒ In(e) ∪ Gen(n2), " run-as edge e = (n1, n2) • 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 Student m0 μ(m0) = Student Student,Assistant Student,Assistant Professor μ(m1) = StudentÚAssistant m1 m2 π(m1) = π(m4) = Professor Student Professor Professor Professor Professor m3 m4 m5 μ(m3) = Professor μ(m5) = Professor Student Student Student m6 m7 μ(m7) = Student μ(m6) = Student

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

19. Traditional StaticAnalysis Engine ESPE Bean1Bean.m1() Bean1Bean.m1() Bean2.m2() Bean2.m2() Bean2Bean.m2() Modeling Remote Method Invocations 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 <ejb-name>Bean1Bean</ejb-name> <home>Bean1Home</home> <remote>Bean1</remote> <ejb-class>Bean1Bean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Bean1</transaction-type> <ejb-ref> <ejb-ref-name>ejb/Bean2</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>Bean2Home</home> <remote>Bean2</remote> <ejb-class>Bean2Bean</ejb-class> </ejb-ref>

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 • Defined theoretical foundation for RBAC consistency and policy validations • Introduced and implemented static analysis models • Static analyzer tailored to Java EE applications • Experimental results have shown zero false positives

23. Thank You!