1 / 80

Logic and Logic Programming in Distributed Access Control (Part Two)

Logic and Logic Programming in Distributed Access Control (Part Two). Ninghui Li Department of Computer Science and CERIAS Purdue University. Outline. Security analysis for RT 0 RT: a family of Role-based Trust-management languages

luisa
Download Presentation

Logic and Logic Programming in Distributed Access Control (Part Two)

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. Logic and Logic Programming in Distributed Access Control (Part Two) Ninghui Li Department of Computer Science and CERIAS Purdue University Ninghui Li (Purdue University)

  2. Outline • Security analysis for RT0 • RT: a family of Role-based Trust-management languages • Constraint Datalog as a semantic foundation for TM languages • Open problems in trust management • Other application areas of logic & logic programming in access control Ninghui Li (Purdue University)

  3. Security Analysis in Trust Management • Publications: • Li, Winsborough & Mitchell: “Beyond Proof-of-Compliance: Safety and Availability Analysis in Trust Management”, S&P’03 • Li, Mitchell & Winsborough: “Beyond Proof-of-Compliance: Security Analysis in Trust Management”, submitted. Ninghui Li (Purdue University)

  4. The Abstract Security Analysis Problem • Given an initial state P, • a query Q, • and a rule Rthat restricts how states can change (defines reachability among states); • Ask • Is Q possible? (existential) • whether  reachable P’ s.t. P’  Q • Is Q necessary? (universal) • whether  reachable P’ , P’  Q Ninghui Li (Purdue University)

  5. Statements in RT0= RT[,] • Type-1: K.r  K1 • mem[K.r]  {K1} • KHR.manager  KAlice • Type-2: K.r K1.r1 • mem[K.r]  mem[K1.r1] • KSSO.admin  KHR.manager Ninghui Li (Purdue University)

  6. Statements in RT[,] • Type-3: K.r K.r1.r2 • Let mem[K.r1] be {K1, K2, , Kn}mem[K.r]  mem[K1.r2]  mem[K2.r2]  mem[Kn.r2] • KSSO.delegAccess  KSSO.admin.access • Type-4: K.r  K1.r1 K2.r2 • mem[K.r]  mem[K1.r2]  mem[K2.r2] • KSSO.accessKSSo.delegAccessKHR.employee Ninghui Li (Purdue University)

  7. The Query Q • Form-1: mem[K.r] {K1,,Kn} ? • Form-2: {K1,,Kn}  mem[K.r] ? • Form-3: mem[K1.r1]  mem[K.r] ? Ninghui Li (Purdue University)

  8. The Semantic Relation  • A statement  a Datalog rule • K.r  K2  m(K, r, K2) • K.r K1.r1 m(K, r, z) :- m(K1, r1, z) • … • A state P  a Datalog program SP[P] • mem[K.r]  { K’ | m(K,r,K’) is in the minimal Herbrand model of SP[P] } Ninghui Li (Purdue University)

  9. Example Queries & Answers • KSSO.access  KSSO.admin • KSSO.admin  KHR.manager • KHR.employee  KHR.manager • KHR.manager  KAlice • KHR.employee  KDavid mem[KSSO.access]  {KDavid}?No {KAlice, KDavid}  mem[KSSO.employee]? Yes mem[KHR.employee]  mem[KSSO.access]? Yes Ninghui Li (Purdue University)

  10. The Restriction Rule R • R=(G,S) • G is a set of growth-restricted roles • if A.r  G, then cannot add “A.r ” • S is a set of shrink-restricted roles • if A.r  S, then cannot remove“A.r ” • Motivation: • Definitions of roles that are not under one’s control may change Ninghui Li (Purdue University)

  11. Sample Analysis Queries • Simple safety (existential form-1): • Is mem[K.r]  {K1} possible? • Simple availability (universal form-1): • Is mem[K.r]  {K1} necessary? • Bounded safety (universal form-2): • Is {K1,,Kn}  mem[K.r] necessary? • Containment (universal form-3): • Is mem[K1.r1]  mem[K.r] necessary? Ninghui Li (Purdue University)

  12. Security Analysis: Usage Cases • Guarantee safety and availability properties of an access control system: • Properties one wants to guarantee are encoded in a set of queries & desirable answers • R represents how much control one has • parts not under one’s control may change in R • parts under one’s control are considered fixed in R • Before making changes, one can use analysis to guarantee properties are not violated Ninghui Li (Purdue University)

  13. An Example • KSSO.accessKSSO.admin • KSSO.access KSSO.delegAccess KHR.employee • KSSO.adminKHR.manager • KSSO.delegAccess KSSO.admin.access • KHR.employeeKHR.manager • KHR.employeeKHR.engineer • KHR.manager KAlice • Alice.access KBob Legend: fixed can grow, can shrink Ninghui Li (Purdue University)

  14. A Simple Availability Query • KSSO.accessKSSO.admin • KSSO.access  KSSO.delegAccess  KHR.employee • KSSO.adminKHR.manager • KSSO.delegAccess  KSSO.admin.access • KHR.employee  KHR.manager • KHR.employee  KHR.engineer • KHR.manager KAlice • Alice.access  KBob Query: Is mem[KSSO .access] {KAlice} necessary? Answer: Yes. (Available) Why: Statments 1, 3, and 7 cannot be removed Ninghui Li (Purdue University)

  15. A Simple Safety Query • KSSO.access  KSSO.admin • KSSO.access KSSO.delegAccessKHR.employee • KSSO.adminKHR.manager • KSSO.delegAccess KSSO.admin.access • KHR.employee  KHR.manager • KHR.manager KAlice • KHR.employeeKHR.engineer • KAlice.access KBob Query: Is mem[KSSO.access]  {KEve} possible? Answer: Yes. (Unsafe) Why: Both KHR.engineer and KAlice.accessmay grow. Ninghui Li (Purdue University)

  16. A Containment Analysis Query about Safety • KSSO.accessKSSO.admin • KSSO.access KSSO.delegAccessKHR.employee • KSSO.adminKHR.manager • KSSO.delegAccess  KSSO.admin.access • KHR.employeeKHR.manager • KHR.employee  KHR.engineer • KHR.manager  KAlice • KAlice.access  KBob Query: Is mem[KHR.employee]  mem[KSSO.access] necessary? Answer: Yes. (Safe) Why: KSSO.access and KSSO.admin cannot grow and Statement 5 cannot be removed. Ninghui Li (Purdue University)

  17. An Containment Analysis Query about Availability • KSSO.accessKSSO.admin • KSSO.access  KSSO.delegAccess  KHR.employee • KSSO.adminKHR.manager • KSSO.delegAccess  KSSO.admin.access • KHR.employee  KHR.manager • KHR.employee  KHR.engineer • KHR.manager  KAlice • Alice.access  KBob Query: Is mem[KSSO.access]  mem[KHR.manager] necessary? Answer: Yes. (Available) Why: Statements 1 and 3 cannot be removed Ninghui Li (Purdue University)

  18. Answering Form-1 and Form-2 Queries: Intuitions (1) • RT[,] is monotonic • more statements derive more role memberships • Form-1 queries are monotonic • mem[K.r] {K1,,Kn} • universal form-1 queries can be answered by considering a lower-bound (minimum) state • existential form-1 queries can be answered by considering an upper-bound (maximal) state Ninghui Li (Purdue University)

  19. Answering Form-1 and Form-2 Queries: Intuitions (2) • Form-2 queries are anti-monotonic • {K1,,Kn}  mem[K.r] • universal form-2 queries can be answered by considering the upper-bound state • existential form-1 queries can be answered by considering the lower-bound state • Given P and R, the lower-bound state uniquely exists, we denote it P|R • it can be reached by removing all removable statements Ninghui Li (Purdue University)

  20. The Lower-Bound Program LB(P,R) • For each K.r  K1in P|R, add lb(K, r, K1) • For each K.r K1.r1 in P|R, add lb(K, r, ?Z) :- lb(K1, r1, ?Z) • For each K.r K.r1.r2 in P|R, add lb(K, r, ?Z) :- lb(K, r1, ?Y), lb(?Y, r2, ?Z) • For each K.r  K1.r1 K2.r2 in P|R, add lb(K, r, ?Z) :- lb(K1, r1, ?Z), lb(K2, r2, ?Z) Ninghui Li (Purdue University)

  21. Using the lower-bound program • To answer whether a form-1 query mem[K.r] {K1,,Kn} is necessary, • check whether LB(P,R) |= lb(K,r,K1)  lb(K,r,Kn) • To answer whether a form-2 query {K1,,Kn}  mem[K.r] is possible • check whether {K1,,Kn} { Z | LB(P,R) |= lb(K,r,Z) } Ninghui Li (Purdue University)

  22. The Upper-Bound Program UB(P,R) • Add ub(T, ?r, ?Z) • For each K.r that can grow, add ub(K, r, ?Z) • For each K.r  K1in P, add ub(K, r, K1) • For each K.r K1.r1 in P, add ub(K, r, ?Z) :- ub(K1, r1, ?Z) • For each K.r K.r1.r2 in P, add ub(K, r, ?Z) :- ub(K, r1, ?Y), ub(?Y, r2, ?Z) • For each K.r  K1.r1 K2.r2 in P, add ub(K, r, ?Z) :- ub(K1, r1, ?Z), ub(K2, r2, ?Z) Ninghui Li (Purdue University)

  23. Using the upper-bound program • A form-1 query mem[K.r] {K1,,Kn} is possible iff. any of the following is true, • K.r is not growth restricted • up(K,r,T) is true • UB(P,R) |= ub(K,r,K1)  ub(K,r,Kn) • A form-2 query {K1,,Kn}  mem[K.r] is necessary iff. • {K1,,Kn}  { Z | UB(P,R) |= ub(K,r,Z) } Ninghui Li (Purdue University)

  24. What about Form-3 Queries? • Form-3: mem[K1.r1]  mem[K.r] • Neither monotonic nor anti-monotonic • cannot use the minimal state or the maximal state • Difficulty: adding new members to K.r may affect K1.r1 • We only consider analysis asking whether mem[K1.r1]  mem[K.r] is necessary • we call this containment analysis Ninghui Li (Purdue University)

  25. Complexity Results for Containment Analysis • RT[]: just type 1 and 2 statements • containment analysis is in PTIME • RT[]: type 1, 2, and 4 statements • containment analysis is coNP-complete • RT[]: type 1, 2, and 3 statements • containment analysis is PSPACE-complete • remains PSPACE-complete without shrinking • coNP-complete without growing • RT[,]: decidable in coNEXP Ninghui Li (Purdue University)

  26. Containment Analysis in RT[] • Two cases that X.u contains K.r • the containment is forced by statements in P and cannot be removed • the containment is caused by nonexistence of statements • e.g., when no statement defines K.r and K.r cannot grow, K.r is contained in every role • direct translation of this intuition into a positive logic program does not work • e.g., P={“K.rK1.r1”, “K1.r1K.r”, “K.rK2”, “X.u K2”}, both K.r and K1.r1 are fixed, does X.u contain K.r? Ninghui Li (Purdue University)

  27. The Containment Program for RT[]: BCP(P,R) • Starts from LB(P,R) • Add fc(?X,?u,?X,?u) • For each K.r K1.r1 in P|R, add fc(K,r,?Z,?w) :- fc(K1,r1,?Z,?w) • For each K.r that can grow, add nc(?X,?u,K,r) :- ~ fc(?X,?u,K,r) • For each K.r K1 in P s.t. K.r can’t grow, add nc(?X,?u,K,r) :- ~ fc(?X,?u,K,r), lb(?X,?u,K1) • For each K.r K1.r1 in P s.t. K.r can’t grow, add nc(?X,?u,K,r) :- ~fc(?X,?u,K,r), nc(?X,?u,K1,r1) Ninghui Li (Purdue University)

  28. Solving Containment Analysis in RT[] Using Negation • BCP(P,R) is stratified • we use the perfect model semantics • Theorem: BCP(P,R) |= nc(X,u,A,r) is true iff. X.u does not contain A.r Ninghui Li (Purdue University)

  29. Containment Analysis in RT[] is coNP-complete • It is in coNP, because a counter example can be found by considering just one new principal • That it is coNP-hard is shown by reducing the monotone 3-SAT problem to it • intersection is conjunction, • a role may be defined by multiple statements (implicit disjunction) • containment equivalent to determining validity of formulas like 1 2 • where1are 2 positive propositional formulas Ninghui Li (Purdue University)

  30. Containment Analysis in RT[] • First consider the case that no shrinking is allowed in R • View statements as rewriting rules • A.r D A r to D • A.r  B.r1 A r to B r1 • A.r  A.r1.r2 A r to A r1 r2 • A string has the form A r1 r2 r3 r4 • Lemma 0: SP[P] proves m(A,r,D) iff. the string A r rewrites into D using P Ninghui Li (Purdue University)

  31. Stack: Stack: r1 r2 r u1 u1 u2 u2 ... ... State: A State: A RT[] and Pushdown Systems Apply the rewriting rule: A r to A r1 r2 A string corresponds to a configuration “rewrites into” equivalent to “reaches” Ninghui Li (Purdue University)

  32. Characteristic Set of a Role • Given P and R (shrinking forbidden), define: • strsP[A.r] = sets of strings A r rewrites to • XR = the set consisting of • all principals • all strings that start with a g-unrestricted role, i.e., B r1 r2 r3 r4 where B r1 is g-unrestricted • XP,R[A.r] = strsP[A.r]  XR • each string B r1 r2 r3 r4 in XP,R[A.r] is a distinct way of adding a member to A.r • Lemma 1: Given P, R, X.u, A.r, mem[X.u] mem[A.r] is necessary iff. XP,R[X.u]  XP,R[A.r] Ninghui Li (Purdue University)

  33. Lemma 2: • Lemma 2: Given P, R (shrinking forbidden), and A.r, XP,R[A.r] is recognized by an NFA that has size poly in |P|+|R| • Proof: XP,R[A.r] = strsP[A.r]  XR • strsP[A.r] is recognized by a poly-size NFA • Bouajjani, Esparza & Maler: “Reachability Analysis of Pushdown Automata: Application to Model-Checking”, CONCUR’97 • XR is recognized by a poly-size NFA • XP,R[A.r] is recognized by a poly-size NFA Ninghui Li (Purdue University)

  34. Containment Analysis in RT[] is in PSPACE • Theorem: Given P, R (shrinking forbidden), X.u, A.r, determining whether mem[X.u] mem[A.r] is necessary is in PSPACE • follows from Lemma 1 and 2 and the fact that determining containment of languages accepted by NFA’s is in PSPACE Ninghui Li (Purdue University)

  35. Containment Analysis in RT[] is PSPACE-hard • Theorem: Given P, R (shrinking forbidden), X.u, A.r, determining whether mem[X.u] mem[A.r] is necessary is PSPACE-hard • Reducing determining containment of languages over the alphabet {0,1} that are defined by right-linear grammars to the problem. Ninghui Li (Purdue University)

  36. Proof of PSPACE-hardness • From grammar to P: • N1 ::= N2 1 A.N1 = A.N2.r1 • N2 ::= 0 A.N2 = B.r0 • The restriction rule R: • all A.Ni’s are g-restricted • B.r0 and B.r1 are g-unrestricted • Language[N1] maps to XP,R[A.N1] • N1 generates 1010 iff. B.r1.r0.r1.r0XP,R[A.N1] Ninghui Li (Purdue University)

  37. Theorem (shrinking allowed) • Given P, R (shrinking allowed), X.u, A.r, determining whether mem[X.u] mem[A.r] is necessary is in PSPACE • For every subset of P that can be obtained by legally removing statements in P, run the algorithm that does not allow shrinking Ninghui Li (Purdue University)

  38. Containment Analysis in RT[] • Theorem: Given P (in RT[]), R, X.u, A.r, determining whether mem[X.u] mem[A.r] is necessary is in coNEXP • although infinitely many new principals and statements may be added, if a counter example exists, then a counter example of size exponential in P exists • if two new principals have the same memberships in all roles appearing in P, then the two principals can be collapsed into one Ninghui Li (Purdue University)

  39. Summary of Complexities for Containment Analysis Type-1 and 2: PTIME Type-1, 2, and 3: PSPACE-complete Type-1, 2, and 4: coNP-complete Type-1, 2, 3, and 4: PSPACE-hard, coNEXP Ninghui Li (Purdue University)

  40. Outline • Security analysis for RT0 • RT: a family of Role-based Trust-management languages • Constraint Datalog as a semantic foundation for TM languages • Open problems in trust management • Other application areas of logic & logic programming in access control Ninghui Li (Purdue University)

  41. RT: a family of Role-based Trust-management languages • Publications: • Li, Mitchell & Winsborough: “Design of A Role-based Trust-management Framework”, S&P’02 Ninghui Li (Purdue University)

  42. Features of the RT family of TM languages • Expressive delegation constructs • Permissions for structured resources • A tractable logical semantics based on Constraint Datalog • Strongly-typed credentials and vocabulary agreement • Efficient deduction with large number of distributedpolicy statements • Security analysis Ninghui Li (Purdue University)

  43. Expressive Features (part one) • Simple attribute assignmentStateU.stuID  Alice • Delegation of attribute authority StateU.stuID  COE.stuID • Attribute inferencing EPub.access  EPub.student • Attribute-based delegation of authority EPub.student  EPub.university.stuID Ninghui Li (Purdue University)

  44. Expressive Features (part two) • Conjunction EPub.access  EPub.student  ACM.member • Attributes with fields • StateU.stuID (name=.., program=.., …)  Alice • EPub.access  StateU.stuID(program=“graduate”) • Permissions for structured resources • e.g., allow connection to any host in a domain and at any port in a range Ninghui Li (Purdue University)

  45. The Languages in the RT Framework RT0: Decentralized Roles RTD: forSelective Use of Role memberships RTT : forSeparation of Duties RT1: Parameterized Roles RT2: Logical Objects RT1C: structured resources RT2C: structured resources RTT and RTD can be used (either together or separately) with any of the five base languages: RT0, RT1, RT2, RT1C, and RT2C Ninghui Li (Purdue University)

  46. RT1 = RT0 + Parameterized Roles • Motivations: to represent • attributes that have fields, e.g., digital ids, diplomas • relationships between principals, e.g., physicianOf, advisorOf • role templates, e.g., project leaders • Approach: • a role term R has a role name and a list of fields Ninghui Li (Purdue University)

  47. RT1 (Examples) • Example 1: Alpha allows manager of an employee to evaluate the employee: Alpha.evaluatorOf(employee=y) Alpha.managerOf(employee=y) • Example 2: EPub allows CS students to access certain resources: EPub.access(action=‘read’, resource=‘file1’)  EPub.university.stuID(dept=‘CS’) Ninghui Li (Purdue University)

  48. RT1 (Technical Details) • A credential takes one of the following form: • A.r(h1, ..., hn) D • A.r(h1, ..., hn) B.r1(s1, ..., sm) • A.r(h1, ..., hn) A.r1(t1, ..., tL).r2(s1, ..., sm) • A.R B1.R1 B2.R2 ...  Bk.Rk • Each variable • must have a consistent data type across multiple occurrences • can have zero or more static constraints • must be safe, i.e., must appear in the body Ninghui Li (Purdue University)

  49. Semantics and Complexity for RT1 • LP semantics makes each role name a predicate • E.g., A.r(h1, …, hn) B.r1(s1, …, sm) translates tor(A, h1, …, hn, ?X) :- r1 (B, s1, …, sm, ?X) • Apply known complexity results: The atomic implications of SP(P )can be computed in O(Nv+3) • v is the max number of variables per statement • Each role name has a most p arguments • N = max(N0, pN0), N0is the number of statements in P Ninghui Li (Purdue University)

  50. RT2 = RT1 + Logical Objects • Motivations: • to group logically related objects together and assign permissions about them together • Approach: introducing o-sets, which are • similar to roles, but have values that are sets of things other than entities • defined through o-set definition credentials, which are similar to role-definition credentials in RT1 Ninghui Li (Purdue University)

More Related