1 / 56

Verification and Change-Impact Analysis of Access-Control Policies

Verification and Change-Impact Analysis of Access-Control Policies. Kathi Fisler (WPI) joint work with Shriram Krishnamurthi (Brown) Dan Dougherty (WPI). Representative Feature. Conference Subreviews. Alice (PC member). PC chair. “delegate to subreviewer”. su to Alice. mail form URL.

warren
Download Presentation

Verification and Change-Impact Analysis of Access-Control Policies

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. Verification and Change-Impact Analysis of Access-Control Policies Kathi Fisler (WPI) joint work with Shriram Krishnamurthi (Brown) Dan Dougherty (WPI)

  2. Representative Feature

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

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

  5. System Structure

  6. System Structure = +

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

  8. A First View of Policy Analysis

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

  10. 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)

  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 Basic Policy Verification Counterexample: subj:student Ùsubj:faculty Ù action:receive Ù resource:grades

  12. 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)

  13. Properties?!?

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

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

  16. 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, …}

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

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

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

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

  21. Implementation

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

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

  24. Rules and Rule Combination

  25. Faculty are disjoint from Students Constraints X

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

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

  28. 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”

  29. Beyond Roles:Reasoning about Instances

  30. 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?

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

  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 Programs provide policy environments!

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

  34. Reasoning About Policies in their Dynamic Environments

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

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

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

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

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

  40. 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”)

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

  42. 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))

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

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

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

  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 Lemma (modular reasoning): If Pol2 uniformly extends Pol1, then for all policies P, P È Pol2 uniformly extends P È Pol1

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

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

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

More Related