when role models have flaws: static validation of enterprise security policies

When Role Models Have Flaws:Static Validation

of Enterprise Security Policies

Marco PistoiaIBM T. J. Watson Research Center

Hawthorne, New [email protected]

Stephen J. FinkIBM T. J. Watson Research Center


Robert J. FlynnPolytechnic UniversityBrooklyn, New York

[email protected]

Eran YahavIBM T. J. Watson Research Center


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 invokemethod setGradesPermission to invokemethod setGrades

Permission to invokemethod assignHomework

Permission to invokemethod 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

<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>

<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

Role Required: Student

Role Required: Student or Assistantrun-as: Professor

Role Required: Professor Role Required: Professor

Component

Intercomponent call

Intracomponent call

SubversiveSubversive

InsufficientInsufficient

RedundantRedundant

m0m0

m1m1 m2m2

m3m3 m4m4 m5m5

m6m6 m7m7

Role Required: Student Role Required: Student


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 B(R) is the principal delegation partial function Roles Granted:Student, Assistant




Component

Intercomponent call

Intracomponent callm0m0

m1m1 m2m2

m3m3 m4m4 m5m5

m6m6 m7m7


User: bobυ(bob) = Student Assistantυ(bob) = Student Assistant

μ(m1) = Student Assistantμ(m1) = Student Assistant

π(m1) = π(m4) = Professorπ(m1) = π(m4) = Professor

μ(m6) = Studentμ(m6) = Student


μ(m5) = Professorμ(m5) = 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)

• <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>




Role Required: Professor

Component

Intercomponent call


m1m1

m3m3 m4m4






Init – User u calls entry point m'

υ(bob) = Student Assistant ⇒ μ(m0) = Studentυ(bob) = Student Assistant ⇒ μ(m0) = Student

Call – Method m calls method m'

S1S1

Return – Method m' returns to method m

εε

S2S2 υ(bob) = Student Assistantυ(bob) = Student Assistant

S3S3υ(bob) = Student Assistant ⇒ μ(m1) = Student Assistantυ(bob) = Student Assistant ⇒ μ(m1) = Student Assistant S5S5 υ(bob) = Student Assistantυ(bob) = Student Assistant

(m1) = Professor ⇒ μ(m3) = Professor(m1) = Professor ⇒ μ(m3) = Professor S4S4 (m1) = Professor(m1) = ProfessorS6S6 (m1) = Professor(m1) = Professor(m1) = Professor ⇒ μ(m4) = (m1) = Professor ⇒ μ(m4) =

9

Modified Instrumentation





Component

Intercomponent call


m1m1

m3m3 m4m4







Intercomponent Call – m calls m', md(m) ≠ md(m')

S1S1


εε


S3S3S5S5 υ(bob) = Student Assistantυ(bob) = Student Assistant


Intracomponent Call – m calls m', md(m) = md(m')

10

Concrete Instrumented Semantics <S,w>





Component

Intercomponent call


m1m1

m3m3 m4m4







υ(bob) = Student Assistant ⇒ μ(m0) = Studentυ(bob) = Student Assistant ⇒ μ(m0) = Student

Call – Method m calls method m'

S1S1


εε


S3S3υ(bob) = Student Assistant ⇒ μ(m1) = Student Assistantυ(bob) = Student Assistant ⇒ μ(m1) = Student Assistant S5S5 υ(bob) = Student Assistantυ(bob) = Student Assistant

(m1) = Professor ⇒ μ(m3) = Professor(m1) = Professor ⇒ μ(m3) = Professor S4S4 (m1) = Professor(m1) = ProfessorS6S6 (m1) = Professor(m1) = Professor(m1) = Professor ⇒ μ(m4) = (m1) = Professor ⇒ μ(m4) =

11

Modified Instrumentation





Component

Intercomponent call


m1m1

m3m3 m4m4







Intercomponent Call – m calls m', md(m) ≠ md(m')

S1S1


εε


S3S3S5S5 υ(bob) = Student Assistantυ(bob) = Student Assistant


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) ⇒ μ(me), e does not transition to an authorization error state; insufficient otherwise

• Insufficient policies can lead to stability problems

Roles Granted:Student




Component

Intercomponent call

Intracomponent call


m0m0

m1m1 m2m2

m3m3 m4m4 m5m5

m6m6 m7m7



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




Component

Intercomponent call

Intracomponent call

RedundantRedundant

m0m0

m1m1 m2m2

m3m3 m4m4 m5m5

m6m6 m7m7


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 PrivilegeRoles Granted:Student




Component

Intercomponent call

Intracomponent call

SubversiveSubversive

m0m0

m1m1 m2m2

m3m3 m4m4 m5m5

m6m6 m7m7


User: bob

15

Analysis Domain

r1r1

r2,r3r2,r3

r4r4

r1,r5r1,r5

r1r1

r2,r3r2,r3

r4r4

r1,r5r1,r5

r1 r5

(r1 r5) (r2 r3)

r1 r5

r1 r5

r1 r5

r1 (r1 r5) (r2 r3) • μ : 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

m0m0

m1m1 m2m2

m3m3 m4m4 m5m5

m6m6 m7m7




μ(m6) = Studentμ(m6) = Student μ(m7) = Studentμ(m7) = Student




StudentStudent

ProfessorProfessor

StudentAssistantStudentAssistant

ProfessorProfessor

StudentStudent

StudentStudent StudentStudent

StudentAssistantStudentAssistant

ProfessorProfessor

ProfessorProfessor

StudentStudent ProfessorProfessor

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

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

Modeling Remote Method Invocations

Bean1Bean.m1()

Bean2.m2()

Traditional StaticAnalysis 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

<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>

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

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!

when role models have flaws: static validation of enterprise security policies

Documents