Verification and Change-Impact Analysis of Access-Control Policies

1. Verification and Change-Impact Analysis of Access-Control Policies Kathi Fisler (WPI) joint work with Shriram Krishnamurthi (Brown) Dan Dougherty (WPI)

3. Representative Feature

4. Conference Subreviews Alice (PC member) PC chair “delegate to subreviewer” su to Alice mail form URL click Subreviewer

5. Modern Access-Control Policies Policy maps requests to decisions: <subject, action, resource> g {permit, deny} role not-applicable university policy on building access department policy: undergrad TAs get night access

6. System Structure

7. System Structure = +

8. Access-Control Languages • Modularity • Control flow • Accessing databases of information • policies are becoming “software” New standards include XACML, EPAL, etc.

9. A First View of Policy Analysis

10. Example: Gradebook • Roles: Faculty, Student, TA • Actions: Assign, View, Receive • Resources: Grades

11. Requests for Students to ReceiveGrades succeed Requests for Faculty to Assign or ViewGrades succeed No Student can AssignGrades No single person can both Receive and AssignGrades Policies and Properties subj:student Ù action:receive Ù resource:grades g Permit Ø$ s : (subj:s Ù action:receive Ù resource:grades g Permit) Ù(subj:s Ù action:assign Ù resource:grades g Permit)

12. Requests for Students to ReceiveGrades succeed Requests for Faculty to Assign or ViewGrades succeed No Student can AssignGrades No single person can both Receive and AssignGrades Basic Policy Verification Counterexample: subj:student Ùsubj:faculty Ù action:receive Ù resource:grades

13. Requests for Students to ReceiveGrades succeed Requests for Faculty to Assign or ViewGrades succeed Faculty are disjoint from Students No Student can AssignGrades No single person can both Receive and AssignGrades Basic Policy Verification Ø(subj:student Ù subj:faculty)

14. Properties?!?

15. Policies Without Properties • Working policy P1 • Modified policy P2 • Testing reveals intended change • But…

16. Requests for Students to ReceiveGrades succeed Requests for Faculty to Assign or ViewGrades succeed TAs have the same privileges as Faculty Faculty are disjoint from Students Requests for Students to ReceiveGrades succeed Requests for Faculty to Assign or ViewGrades succeed Faculty are disjoint from Students Comparing Policies Compute semantic difference of policies

17. Defining Difference A difference is a function mappingrequests to kinds of change E.g.: {“TA can assign grades”  NAPermit, “TA can view grades”  NAPermit, …}

18. Output Faculty 0 0 0 0 0 0 0 0 Student 0 0 0 0 1 1 1 1 Grades 1 1 0 0 1 1 0 0 Assign 0 1 0 1 0 1 0 1 View 1 0 1 0 1 0 1 0 Receive 0 0 0 0 0 0 0 0 TA 1 1 1 1 1 1 1 1 N N N N N N N N 2 2 2 2 2 2 2 2 P P P P P P P P

19. Faculty 0 0 0 0 0 0 0 0 Student 0 0 0 0 1 1 1 1 Grades 1 1 0 0 1 1 0 0 Assign 0 1 0 1 0 1 0 1 View 1 0 1 0 1 0 1 0 Receive 0 0 0 0 0 0 0 0 TA 1 1 1 1 1 1 1 1 N N N N N N N N 2 2 2 2 2 2 2 2 P P P P P P P P Faculty 0 0 Student 0 1 Grades 1 1 Assign 1 1 View 0 0 Receive 0 0 TA 1 1 N N 2 2 P P Output Show cases involving grade assignment

20. Student TA Faculty 0 0 Student 0 1 Grades 1 1 Assign 1 1 View 0 0 Receive 0 0 TA 1 1 N N 2 2 P P Output Show all roles

21. Margrave • Policies: mappings from attribute values to decisions (permit/deny/not-applicable) • Properties: First-order logic assertions over boolean combinations of attribute values • Queries over policy differences • Restrict by change type (eg, D->P) • Restrict to boolean combinations attribute values • List roles, actions, resources occurring in change • Emptiness

22. Implementation

23. Possibilities Reasoning is largely propositional • CNF/DNF • Prolog • SAT solving (Alloy?) • Decision diagrams

24. Faculty (f) can assign (a) grades (g) Students (s) can receive (r) grades (g) Multi-TerminalDecision Diagrams

25. Rules and Rule Combination

26. Faculty are disjoint from Students Constraints X

27. Policy Differencing • Decision diagram with 16 terminals: permitpermit, permitdeny, denypermit, denynot-applicable, … • Built from policies using minor variations of standard decision diagram combinators • Similar core representation to policies

28. Continue Performance • Policy has 50 MTDD variables • Policy has 1268 nodes (817 w/ constraints) • Twelve properties: each < 10ms • Memory: 316,288 bytes over baseline • Change: 2ms, 1133 nodes, 16.3Kb memory

29. Margrave in Perspective • Supports a subset of XACML • Good for role-level analysis Limited support for conditions on instances: “TAs may assign grades for courses that they are not taking”

30. Beyond Roles:Reasoning about Instances

31. During the submission phase, an author may submit a paper During the review phase, a reviewer r may submit a review for paper p if r is assigned to review p During the meeting phase, a reviewer r can read the scores for paper p if r has submitted a review for p Authors may never read scores During the submission phase, an author may submit a paper During the review phase, a reviewer r may submit a review for paper p if r is not conflicted with p During the meeting phase, a reviewer can read the scores for paper p if r has submitted a review for p and r is not conflicted with p Authors may never read scores Conference Manager Policies Can the conflict info change?

32. During submission phase, author may submit a paper During review phase, a reviewer r may submit review for paper p if r is assigned to p …. Policies Have Environments phase: submission Submitted(Jane,P1) Submitted(Abe,P2) phase: review Assigned(Alice,P1) Assigned(Ed,P2) Assigned(Bill,P1) Reviewed(Bill,P1) Conflict(Alice,P1) Can Alice submit a review for P1? no yes

33. During submission phase, author may submit a paper During review phase, a reviewer r may submit review for paper p if r is assigned to p …. Policies Have Environments Programs provide policy environments!

34. The Content of Environments Program data (who has submitted reviews) Program data (conference phase) Policy information (role hierarchy) Run-time data (time) User data (credentials) Policy is static – environment is dynamic

35. Reasoning About Policies in their Dynamic Environments

36. Models: Policies Model policies as Datalog rules: • Permit(a, submit-paper, p) :- author(a) Ù paper(p) Ù phase(submission) • Permit(r, submit-review, p) :- reviewer(r) Ù assigned(r,p) Ù phase(review) • Deny(a, read-scores, p) :- author(a) Ù paper(p) Two possible rule heads (idbs): Permit, Deny Body relations (edbs) defined by application

37. Models: Policy Environments At any instant, environment defines a set of relational (edb) facts • Submitted(Jane,P1) • Assigned(Bill,P2) • phase(review) Environment is a transition system over sets of relational facts

38. Datalog facts decs facts decs facts decs facts decs Models: Policies in Environments decisions over time: captures program impact on decisions facts over time

39. func UploadReview(a, p) { if Permit == CheckReq (a,submit-review,p) Reviews := Review U (a, p) …} • During submission phase, author may submit a paper • During review phase, a reviewer r may submit review for paper p if r is assigned to p • …. Policies Influence Programs

40. Datalog facts facts facts facts Models: Policies in Environments decs decs decs decs submit-review(Alice,P1) remove transitions for non-permitted actions

41. Analysis: Model Checking “No reviewer r can ever read the scores for a paper with which r is conflicted” “There always exists a PC chair who can advance the meeting to the next paper” Property Language: First-order LTL/CTL (temporal logic over relational “atoms”)

42. Analysis: Change Impact Two separate problems: • same environment, different policies • same policy, different environments Formal statement: Produce pairs (path, request) such that taking path through environment yields different decisions for request

43. Related Question: Policy Containment Is Policy P2 more permissive than P1? Universal quantification over requests makes this expensive to check Better way to compute containment? AG " s,a,r : (Permit1(s,a,r) g Permit2(s,a,r)) Ù (Deny2(s,a,r) g Deny1(s,a,r))

44. Datalog facts facts facts facts Recall Derived Decisions decs decs decs decs Datalog(facts)  decs permitted = Datalog(facts)|Permit

45. Decision Extension Pol2extends Pol1 if for all sets of facts • Pol1(facts)|PermitÍPol2(facts)|Permit • Pol2(facts)|DenyÍPol1(facts)|Deny

46. Uniform Extension Pol2uniformlyextends Pol1 if for all sets of facts and decs • Pol1(facts È decs)|PermitÍPol2(facts È decs)|Permit • Pol2(facts È decs)|DenyÍPol1(facts È decs)|Deny Containment of Datalog programs undecidable, but uniform containment decidable

47. Uniform Extension Pol2uniformlyextends Pol1 if for all sets of facts and decs • Pol1(facts È decs)|PermitÍPol2(facts È decs)|Permit • Pol2(facts È decs)|DenyÍPol1(facts È decs)|Deny Lemma (modular reasoning): If Pol2 uniformly extends Pol1, then for all policies P, P È Pol2 uniformly extends P È Pol1

48. Uniform Extension Pol2uniformlyextends Pol1for program A if for all sets of facts and decs reachable in A • Pol1(facts È decs)|PermitÍPol2(facts È decs)|Permit • Pol2(facts È decs)|DenyÍPol1(facts È decs)|Deny Exploit model of facts provided by program

49. P1 P2 Uniform Extension Captures Some Change-Impact Analysis P2 neither removes permissions from nor adds denials to P1 iff uniformly extends

50. P1 P2 Uniform Extension Captures Some Change-Impact Analysis Does P2 = P1 + Permit(s,a,r)? (one new permission) yes, iff + Permit(s,a,r) is uniformly equivalent with