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)
PC chair
“delegate to subreviewer”
su to Alice
Subreviewer
click
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
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
 Faculty are disjoint from
Students
(subj:student  subj:faculty)
13
Properties?!?
14
Policies Without Properties
•
•
•
•
Working policy P1
Modified policy P2
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

Faculty are disjoint from Students
 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
1
0
0
1
1
0
0
1
0
0
0
0
1
0
1
0
0
0
1
0
0
1
0
1
1
0
1
0
1
0
1
1
1
0
0
1
0
1
0
0
1
0
1
0
1
0
1
0
0
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
Output
Faculty
Student
Grades
Assign
View
Receive
TA
0
0
1
0
1
0
1
0
0
1
1
0
0
1
0
0
0
0
1
0
1
0
0
0
1
0
0
1
0
1
1
0
1
0
1
0
1
1
1
0
0
1
0
1
0
0
1
0
1
0
1
0
1
0
0
1
Faculty
Student
Grades
Assign
View
Receive
TA
N N N N N N N N
2 2 2 2 2 2 2 2
P P P P P P P P
Show cases involving
grade assignment
0
0
1
1
0
0
1
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, 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
Conference Manager Policies
•
During the submission phase, an
author may submit a paper
•
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
•
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,P1)
Submitted(Abe,P2)
phase: review
Assigned(Alice,P1)
Assigned(Ed,P2)
Assigned(Bill,P1)
Reviewed(Bill,P1)
Can Alice submit
no yes
a review for P1?
Conflict(Alice,P1)
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,P1)
– Assigned(Bill,P2)
– phase(review)
Environment is a transition system over sets
of relational facts
37
Models: Policies in Environments
Datalog
decs
decs
decs
facts
decs
facts
facts
facts
facts over time
decisions over time:
captures program impact
on decisions
38
Policies Influence Programs
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
….
39
Models: Policies in Environments
Datalog
decs
decs
decs
facts
facts
decs
submit-review(Alice,P1)
facts
facts
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?
AG " s,a,r : (Permit1(s,a,r) g Permit2(s,a,r)) 
(Deny2(s,a,r) g Deny1(s,a,r))
Universal quantification over requests
makes this expensive to check
Better way to compute containment?
43
Recall Derived Decisions
Datalog
decs
decs
decs
facts
decs
facts
facts
facts
Datalog(facts)  decs
permitted = Datalog(facts)|Permit
44
Decision Extension
Pol2 extends Pol1 if for all sets of facts
– Pol1(facts)|Permit  Pol2(facts)|Permit
– Pol2(facts)|Deny  Pol1(facts)|Deny
45
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
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
Lemma (modular reasoning): If Pol2 uniformly
extends Pol1, then for all policies P, P  Pol2
uniformly extends P  Pol1
47
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
48
Uniform Extension Captures
Some Change-Impact Analysis
P1
P2
P2 neither removes permissions from nor adds
denials to P1 iff
uniformly extends
49
Uniform Extension Captures
Some Change-Impact Analysis
P1
P2
Does P2 = P1 + 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 : (Permit1(s,a,r) g Permit2(s,a,r)) 
(Deny2(s,a,r) g Deny1(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
• 10ms 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