Verification and Change-Impact Analysis of Access-Control Policies Kathi

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

2

Representative Feature 3

Conference Subreviews Alice (PC member) “delegate to subreviewer” L R ail form U m Subreviewer click PC chair su to Alice 4

Modern Access-Control Policies Policy maps requests to decisions: 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

Policies and Properties • Requests for Students to Receive Grades succeed 1. No Student can Assign Grades • Requests for Faculty to Assign or View Grades succeed 2. No single person can both Receive and Assign Grades 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

Basic Policy Verification • Requests for Students to Receive Grades succeed 1. No Student can Assign Grades • Requests for Faculty to Assign or View Grades succeed 2. No single person can both Receive and Assign Grades Counterexample: subj: student Ù subj: faculty Ù action: receive Ù resource: grades 12

Basic Policy Verification • Requests for Students to Receive Grades succeed 1. No Student can Assign Grades • Requests for Faculty to Assign or View Grades succeed 2. No single person can both Receive and Assign Grades v Faculty are disjoint from Students Ø(subj: student Ù subj: faculty) 13

Properties? !? 14

Policies Without Properties • • Working policy P 1 Modified policy P 2 Testing reveals intended change But… 15

Comparing Policies • • Requests for Students to Receive Grades succeed Requests for Faculty to Assign or View Grades succeed • Requests for Students to Receive Grades succeed • Requests for Faculty to Assign or View Grades succeed • TAs have the same privileges as Faculty v Faculty are disjoint from Students Compute semantic difference of policies 16

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

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

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

Output Faculty Student Grades Assign View Receive TA 0 0 1 1 0 0 1 Student TA 0 1 1 1 0 0 1 N N 2 2 P P 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

Multi-Terminal Decision Diagrams • • Faculty (f) can assign (a) grades (g) Students (s) can receive (r) grades (g) 24

Rules and Rule Combination 25

Constraints Faculty are disjoint from Students X 26

Policy Differencing • Decision diagram with 16 terminals: 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 < 10 ms Memory: 316, 288 bytes over baseline Change: 2 ms, 1133 nodes, 16. 3 Kb 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

Conference Manager Policies • 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 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 r can read the scores for paper p if r has submitted a review for 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 Can the conflict info change? 31

Policies Have Environments phase: submission • • • 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 …. Submitted(Jane, P 1) Submitted(Abe, P 2) phase: review Assigned(Alice, P 1) Assigned(Ed, P 2) Assigned(Bill, P 1) Reviewed(Bill, P 1) Can Alice submit no yes a review for P 1? Conflict(Alice, P 1) 32

Policies Have Environments • • • 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 …. Programs provide policy environments! 33

The Content of Environments Program data (who has submitted reviews) Program data (conference phase) User data (credentials) Policy information (role hierarchy) Run-time data (time) 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, P 1) – Assigned(Bill, P 2) – phase(review) Environment is a transition system over sets of relational facts 37

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

Policies Influence Programs func Upload. Review(a, p) { if Permit == Check. Req (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 …. 39

Models: Policies in Environments Datalog decs facts submit-review(Alice, P 1) facts decs 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 P 2 more permissive than P 1? AG " s, a, r : (Permit 1(s, a, r) g Permit 2(s, a, r)) Ù (Deny 2(s, a, r) g Deny 1(s, a, r)) Universal quantification over requests makes this expensive to check Better way to compute containment? 43

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

Decision Extension Pol 2 extends Pol 1 if for all sets of facts – Pol 1(facts)|Permit Í Pol 2(facts)|Permit – Pol 2(facts)|Deny Í Pol 1(facts)|Deny 45

Uniform Extension Pol 2 uniformly extends Pol 1 if for all sets of facts and decs – Pol 1(facts È decs)|Permit Í Pol 2(facts È decs)|Permit – Pol 2(facts È decs)|Deny Í Pol 1(facts È decs)|Deny Containment of Datalog programs undecidable, but uniform containment decidable 46

Uniform Extension Pol 2 uniformly extends Pol 1 if for all sets of facts and decs – Pol 1(facts È decs)|Permit Í Pol 2(facts È decs)|Permit – Pol 2(facts È decs)|Deny Í Pol 1(facts È decs)|Deny Lemma (modular reasoning): If Pol 2 uniformly extends Pol 1, then for all policies P, P È Pol 2 uniformly extends P È Pol 1 47

Uniform Extension Pol 2 uniformly extends Pol 1 for program A if for all sets of facts and decs reachable in A – Pol 1(facts È decs)|Permit Í Pol 2(facts È decs)|Permit – Pol 2(facts È decs)|Deny Í Pol 1(facts È decs)|Deny Exploit model of facts provided by program 48

Uniform Extension Captures Some Change-Impact Analysis P 1 P 2 neither removes permissions from nor adds denials to P 1 iff uniformly extends 49

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

Uniform Extension versus Model Checking The formula AG " s, a, r : (Permit 1(s, a, r) g Permit 2(s, a, r)) Ù (Deny 2(s, a, r) g Deny 1(s, a, r)) captures only policy extension, not uniform extension (which addresses modularity) Check uniform extension via rule simulation 51

Conclusion 52

Many Research Questions • How to express environment models (transition systems over relations)? • How to extract (partial) environment models from program source? • How to perform analyses efficiently? • How to present analysis results to policy authors (often non-programmers)? 53

Perspective • Policy analysis must help non-technical authors • Change query/verification may become a lightweight formal method • 10 ms is interesting… 54

Parting Thoughts • Interesting, important verification arena • New face of multi-lingual programming • Conference software is a research area! 55

CONTINUE (Conference Manager): http: //continue. cs. brown. edu/ Margrave (XACML Analysis): http: //www. cs. brown. edu/ research/plt/software/margrave/ Undergraduate RAs (from Brown): Michael Tschantz (now at CMU) Leo Meyerovich 56