1

Verification and Change-Impact Analysis of

Access-Control Policies

Kathi Fisler (WPI)joint work with

Shriram Krishnamurthi (Brown)

Dan Dougherty (WPI)

2

3

Representative Feature

4

Conference SubreviewsAlice (PC member)

Subreviewer

PC chair“delegate to subreviewer”

su to Alicemail form URL

click

5

Modern Access-Control Policies

Policy maps requests to decisions: <subject, action, resource> {permit, deny}

role not-applicable

university policy on building

accessdepartment 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

Policies and Properties

• Requests for Students to Receive Grades succeed

• Requests for Faculty to Assign or View Grades succeed

1. No Student can Assign Grades

2. No single person can both Receive and Assign Grades

subj:student action:receive resource:grades Permit

s : (subj:s action:receive resource:grades Permit) (subj:s action:assign resource:grades Permit)

12

Basic Policy Verification

• Requests for Students to Receive Grades succeed

• Requests for Faculty to Assign or View Grades succeed

1. No Student can Assign Grades

2. No single person can both Receive and Assign Grades

Counterexample: subj:student subj:faculty action:receive resource:grades

13

Basic Policy Verification

• Requests for Students to Receive Grades succeed

• Requests for Faculty to Assign or View Grades succeed

Faculty are disjoint from Students

1. No Student can Assign Grades

2. No single person can both Receive and Assign Grades

(subj:student subj:faculty)

14

Properties?!?

15

Policies Without Properties

• Working policy P1

• Modified policy P2

• Testing reveals intended change• But…

16

Comparing Policies

• Requests for Students to Receive Grades succeed

• Requests for Faculty to Assign or View Grades succeed

• TAs have the same privileges as Faculty

Faculty are disjoint from Students

• Requests for Students to Receive Grades succeed

• Requests for Faculty to Assign or View Grades succeed

Faculty are disjoint from StudentsCompute semantic difference of policies

17

Defining Difference

A difference is a function mappingrequests to kinds of change

E.g.:{“TA can assign grades” NAPermit, “TA can view grades” NAPermit, …}

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

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

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

Show cases involvinggrade assignment

20

OutputStudentTA

Show all roles

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

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

Multi-TerminalDecision Diagrams

• Faculty (f) can assign (a) grades (g)• Students (s) can receive (r) grades (g)

25

Rules and Rule Combination

26

Constraints

Faculty are disjoint from Students

X

27

Policy Differencing

• Decision diagram with 16 terminals:permitpermit, permitdeny, denypermit, denynot-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

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 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 scoresCan the conflict info change?

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

• ….Assigned(Bill,P1)Assigned(Ed,P2)

Reviewed(Bill,P1)

Assigned(Alice,P1)

Submitted(Abe,P2)

Conflict(Alice,P1)

Submitted(Jane,P1)

phase: submission

Can Alice submita review for P1? yesno

phase: review

33

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!

34

The Content of Environments

Policy is static – environment is dynamic

Program data (who has submitted reviews)

User data (credentia

ls)

Policy information (role hierarchy)

Run-time data

(time)

Program data (conference

phase)

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

Models: Policies in Environments

Datalog

facts

facts

facts

factsdecisions over time:

captures program impacton decisionsfacts over time

decs

decs

decs

decs

39

Policies Influence Programs

• 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

• ….

func UploadReview(a, p) { if Permit == CheckReq (a,submit-review,p) Reviews := Review U (a, p) …}

40

Models: Policies in Environments

Datalog

facts

facts

facts

factsremove transitions

for non-permitted actions

decs

decs

decs

decssubmit-review(Alice,P1)

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) Permit2(s,a,r)) (Deny2(s,a,r) Deny1(s,a,r))

44

Recall Derived Decisions

Datalog

facts

facts

facts

facts

decs

decs

decs

decs

Datalog(facts) decspermitted = Datalog(facts)|Permit

45

Decision Extension

Pol2 extends Pol1 if for all sets of facts

– Pol1(facts)|Permit Pol2(facts)|Permit – Pol2(facts)|Deny Pol1(facts)|Deny

46

Uniform Extension

Pol2 uniformly extends 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

Pol2 uniformly extends 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

Pol2 uniformly extends Pol1 for 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

Uniform Extension Captures Some Change-Impact

Analysis

P2 neither removes permissions from nor adds denials to P1 iff uniformly extends

P1 P2

50

Uniform Extension Captures Some Change-Impact

AnalysisP1 P2

Does P2 = P1 + Permit(s,a,r)? (one new permission)yes, iff

+ Permit(s,a,r) is uniformly equivalent with

51

Uniform Extension versusModel Checking

The formula

captures only policy extension, not uniform extension (which addresses modularity)

Check uniform extension via rule simulation

AG s,a,r : (Permit1(s,a,r) Permit2(s,a,r)) (Deny2(s,a,r) Deny1(s,a,r))

52

Conclusion

53

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)?

54

Perspective

• Policy analysis must help non-technical authors

• Change query/verification may become a lightweight formal method

• 10ms is interesting…

55

Parting Thoughts

• Interesting, important verification arena

• New face of multi-lingual programming

• Conference software is a research area!

56

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