1 / 30

Efficient Policy Analysis for Administrative Role-Based Access Control

Efficient Policy Analysis for Administrative Role-Based Access Control. Scott D. Stoller. Ping Yang. C.R. Ramakrishnan. Mikhail I. Gofman. Motivation for Security Policy Analysis. Problem: Security policies are often enforced by Humans (slow, subject to social engineering, etc.)

arnav
Download Presentation

Efficient Policy Analysis for Administrative Role-Based Access Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Efficient Policy Analysis for Administrative Role-Based Access Control Scott D. Stoller Ping Yang C.R. Ramakrishnan Mikhail I. Gofman

  2. Motivation for Security Policy Analysis • Problem: Security policies are often enforced by • Humans (slow, subject to social engineering, etc.) • Application code in Java, C++, etc. (hard to understand, analyze, and maintain) • Goal: Express security policies in policy languages. • Easier to read, analyze (validate), and maintain • Enforced efficiently and automatically (except for occasional manual override) • Examples: Medical records, financial info, course grades • Research: policy languages, policy analysisalgorithms, policy IDEs, distributed enforcement, …

  3. Administrative Policy Analysis • Large organizations have large and complex policies. • A single administrator can’t manage the entire policy. • A trusted senior administrator delegates partial control over the policy to other administrators by establishing an administrative policy. • Example: president, department chair, dean, faculty, … • Administrative policy: controls changes to the policy. • Analysis goal: Understand the power of groups of administrators. Changes by different admins may interact. • Example: Reachability: Can administrators X and Y together modify the policy so user U has permission P?

  4. Overview • We study analysis for ARBAC97, an administrative policy framework for Role-Based Access Control (RBAC). • Reachability analysis for ARBAC is intractable in general. • Efficient algorithms were known only for significantly restricted cases. • We present more practical analysis algorithms that: • Exploit typical characteristics of realistic policies • Are fixed-parameter tractable (FPT), i.e., have • high complexity W.R.T. a (small) parameter k • low complexity W.R.T. overall problem size, when value of k is fixed.

  5. Outline • Background • Case Studies • Algorithms (Forward and Backward), and Fixed-Parameter Tractability Results • Experimental Results

  6. UA PA User Role Permission Role-Based Access Control (RBAC) • Usersare assigned toroles, e.g., doctor, nurse, patient. • Permissions are associated with roles. • A user has a permission if he is a member of some role with that permission. • RBAC is relatively simple and widely used. User Assignment Permission Assignment

  7. Project Supervisor Tester Programmer Project Member Role Hierarchy • r1 ≥ r2 (r1 is senior to r2) means every member of r1 is also an implicit member of r2. Thus, members of r1 have all the permissions that members of r2 have. • Permission flows up. Membership flows down. • Role hierarchy reduces redundancy, eases administration. • New supervisor is added to one role, instead of four.

  8. Administrative RBAC (ARBAC) • ARBAC is a generic name for administrative policy models for RBAC. • Our model is based on ARBAC97 [Sandhu+ 1997]. • Our ideas are also relevant to other models, such as ARBAC02 [Oh+ 2002], RHA [Crampton+ 2005], UARBAC [Li+ 2007], A-ERBAC [Kern+ 2003]. • ARBAC97 has three components: • User-Role Administration: controls user assignment • Permission-Role Administration: controls permission assignment • Role-Role Administration: controls role hierarchy

  9. ARBAC97 • can_assign(ar, c, r): an administrator in role ar can assign a usersatisfying precondition c to role r. • Precondition: true or c1…cn,where ci is a role r or a negated role r. • Ex.: can_assign(Provost, Professor DeptChair, Dean). • can_revoke(ar, r): an administrator in role ar can remove any userfrom role r. • Don’t bother allowing pre-conditions for revocation. • Separate Administration Restriction:Administrative roles and regular roles are disjoint. Assume it now, relax later.

  10. Analysis Problems for ARBAC97 • User-Role Reachability: Can administrators u1,…,un, using operations allowed by ARBAC policyψ, transform initial RBAC policyγ0 to an RBAC policy in which the target user utis a member of all roles in goal={r1,…, rn}? • Weakest Preconditions: Similar, except the target user’s initial roles are unspecified, and the analysis finds the minimal sets of initial roles for him such that the administrators can achieve the goal. • Containment [Li+ 2006]: Similar to reachability, except the administrators’ goal is to produce an RBAC policy in which members(r1)  members(r2).

  11. Outline • Background • Case Studies • Algorithms (Forward and Backward), and Fixed-Parameter Tractability Results • Experimental Results

  12. Observations from Case Studies • ARBAC policies for a university and a health-care facility. • University roles: admissions officer, professor, department chair, dean, provost, president, … • Health-care facility roles: manager, doctor, patient, … • Observations: • Every can_assign rule has 0 or 1 positive preconditions. • Most roles are non-negative. |goal|≤ 2. • An admin can assign and revoke nearly the same roles. • Separate administration is not satisfied, but a related condition (defined later) is satisfied for most queries. • A role is negative if it appears negated in a precondition.

  13. Outline • Background • Case Studies • Algorithms (Forward and Backward), and Fixed-Parameter Tractability Results • Experimental Results

  14. Forward Algorithm for Reachability • Forward algorithm: Standard reachability computation optimized with a reduction, similar to [Lipton 1975]. • With the separate administration assumption, it suffices to consider the role assignment of the target user u only. • A state is the set of roles that the target useru is in. • Transitions that add non-negative roles are invisible and get combined with a preceding visible transition to form a composite transition. • This is safe because invisible transitionsnever disable other transitions. • Theorem: Reachability is fixed-parameter tractable with respect to the number of negative roles, denoted |NR|.

  15. search direction Backward Algorithm: Stage 1 • Exploit the observation: Each can_assign rule has 0 or 1 positive preconditions. Make this a requirement. • Stage 1. Use backwards search (with reduction) from goal to construct a graph (V, E). Nodes are user assignments (sets of roles). Edges are labeled with can_assign rules. • Every state contains at most |goal| roles. role set of roles can_assign(ar, p  N, r) UA \ {r}  {p} UA rUA

  16. R {I1,I2,…} Backward Algorithm: Stage 2 • Example:initial state= {}, goal = {r3}, can_assign rules are as shown, and can_revoke(ar, r2). Result of Stage 1: • The goal is not reachable, because r1 is irrevocable and disables the last transition. • To detect such situations, Stage 2 performs a forward analysis, labeling each node R with sets I1,I2,… of irrevocable roles. represents states RI1, RI2,… cana(ar, true, r1) cana(ar, r1, r2) cana(ar, r2  r1, r3) Ø r1 r2 r3 {Ø} {Ø} {{r1}} {}

  17. Backward Alg.: Fixed-Parameter Tractability • irrev (“irrevocable roles”): set of roles that administrators in the query can assign users to and cannot revoke users from. • In our case studies,|goal| <= 2and |irrev| ≤ 2. • Theorem: For policies with 0 or 1 positive preconditions per rule,reachability is fixed-parameter tractable with respect to {|goal|, |irrev|}. • Proof sketch: Stage 1: Every state contains at most |goal| roles, so |V| is O(|R|2|goal|), where R is the set of roles. Stage 2: The complexity is O(|V| 22|irrev|). • This is a weaker notion of fixed-parameter tractability, because the complexity is |R|2|goal| instead of |R|c.

  18. Beyond Separate Administration • A role can have regular and administrative permissions. • Administrators may assign themselves to new roles. • Example: DeptChair assigns himself to HonorsPgmDir and then assigns students to HonorsStudent. • Need to track roles of multiple users. Reachability is fixed param. tractable with respect to # neg roles and # admins. • A query satisfies hierarchical role assignment if can_assign(ari, c, r) implies ari≥ r for eachari. Each administrator is already an implicit member of roles to which he can be assigned, so such assignments can be ignored. Algorithms that assume separate administration apply. In our case studies, most queries satisfy this.

  19. Outline • Background • Case Studies • Algorithms (Forward and Backward), and Fixed-Parameter Tractability Results • Experimental Results

  20. Experiments: Case Studies • Evaluate algorithms on case studies and random policies. • Slicingeliminates parts of the policy irrelevant to the given reachability query. Typical static slicing, enhanced to consider positive/negative. Use with forward algorithm. • University policy case study: • 11 administrative roles, 21 other roles • 28 can_assign rules (106 after eliminate role hierarchy) • Health care case study:11 roles, 13 can_assign rules, … • Results: • Forward alg: at most 0.01 sec per query. • Backward alg: at most 0.2 sec per query.

  21. Experiments: Random Policies • Randomly generate policies: vary the size parameters, while maintaining similar characteristics as case studies (distribution of can_assign rules per role, positive and negative preconditions per rule, …) • Measurements confirm polynomial behavior predicted by fixed-parameter tractability results – see next slide. • Forward algorithm with slicing is faster when goal is large, e.g., with |goal|=4, forward alg is 91× faster than backward • Backward algorithm is faster when goal is small and NR is large, e.g., with |goal|=1, |IR|=2, and 0.6 < |NR/R| < 0.9, backward alg is 11× to 30× faster than forward alg.

  22. Related Work • [Harrison+ 1976] shows that safety analysis is undecidable for an access matrix model that allows creation of subjects and objects. • URA97 (User-Role Assignment) does not include creation of users or roles. • [Sistla+ 2006] gives algorithms and complexity results for checking temporal properties of role-based trust management policies controlled by role restrictions. • Role restrictions are a simpler form of administrative policy. • Temporal properties are more complex than reachability.

  23. Related Work • [Li+ 2004] gives polynomial analysis algorithms for two restricted versions of ARBAC97 without negative preconditions. We allow negative preconditions. • [Sasturkar+ 2006] and [Jha+ 2007] both • Prove reachability analysis for URA97 is PSPACE-complete. • Identify some restrictions that make the problem NP-complete or polynomial-time. • Contain no fixed-parameter tractability results, and no algorithms with same fixed-parameter tractability properties as our algorithms. • Assume separate administration.

  24. Contributions and Future Work • With separate administration: • Reachability is fixed-parameter tractable(FPT) with respect to |negativeRoles|. • For policies with 0 or 1 positive precondition per rule, reachability is FPT w.r.t. {|goal|, |irrevocableRoles|}. • Without separate administration: • Above results hold withhierarchical role assignment. • Reachability is fixed-parameter tractable with respect to {|negativeRoles|, |administrators|}. • Future Work: • Role hierarchy changes. Roles with params. Info flow.

  25. Thank You!

  26. Fixed-Parameter Tractability of Reachability • Theorem: Reachability is fixed-parameter tractable W.R.T. the number of negative roles, denoted |NR|. • Proof sketch: We show the forward algorithm runs in time O( f(|NR|) |I|c ) for some f and c. |I| is overall input size. • G: reduced state graph constructed by the algorithm • GN: projection of G onto NR, the set of negative roles. • Map each state {r1,…, rn} to {r1,…, rn}∩ NR. • Each state in G is reachable by a simple path in G, which corresponds to a path in GN that goes around each cycle at most once (going around again would not add any more roles, because non-negative roles are added eagerly). There are at most O(f(|NR|)) such paths, for some f.

  27. Example: Forward Algorithm and FPT Proof • can_assign = {(true, r1), (r1, r2), (¬r1r2, r3)}. • Initial state γ0={}. • goal = {r3}. • Reduced state graph G: {} → {r1, r2} → {r2, r3} • Projection GN of G onto NR={r1}: {} → {r1} • For each state γ in G, there is a path to γ that, when projected onto GN, goes around each cycle at most once. • This implies |G| is O(g(|GN|)) hence is O(f(|NR|)). ←

  28. Backward Alg.: Fixed-Parameter Tractability • Theorem: For policies with 0 or 1 positive preconditions per rule,reachability is fixed-parameter tractable with respect to {|goal|, |irrev|}. • Proof sketch: • Stage 1: The restriction on positive preconditions implies that every state contains at most |goal| roles, so |V| is O(|R|2|goal|), where R is the set of roles. • Stage 2: The complexity is O(|V| 22|irrev|).

More Related