Policy Analysis for
Self-administrated
Role-based Access Control
Gennaro Parlato
U. Southampton, UK
Anna Lisa Ferrara
P. Madhusudan
U. Bristol, UK
UIUC, USA
Role-based Access Control
(RBAC)
RBAC is an access control model
- for large organization
- standard (NIST)
- supported by:
Microsoft SQL Servers, Microsoft Active Directory, SELinux, Oracle DBMS
Users
Roles
Permissions
Permissions are pairs
(object, operation)
UA = Users X Roles
PA = Roles X Permissions
RBAC Example: Hospital
Roles: Doctor, Manager, Nurse, Patient, PrimaryD, Receptionist,…
Permissions: p1= Create_Appointment
p2= View_OldMedicalRecord
p3= View_RecentMedicalRecords
…
UA: (Mary, Receptionist)
(John, Doctor), (John, PrimaryD)
(Jenny, Patient)
(Tim, Doctor)
…
PA: (p1, Receptionist)
(p2, Doctor)
(p3, Doctor)
…
Administrative RBAC
(ARBAC)
• UA and PA relations may change by means of administrative rules:
Roles
Users
Admins
UA
Admins Roles
Permissions
Admin
Actions
PA
• Assign(admin_role, precondition, target_role) Users
- if admin user A has admin_role, then A can assign any user u who
satisfies precondition to target_role
conjunction of literals
over the set of Roles
• Revoke(admin_role, precondition, target_role)
Example of ARBAC Policy
Admins: Manager, Patient, Receptionist,…
Assign Rules
- assign( Manager, ¬Doctor, Receptionist )
- assign( Manager, true,
Nurse )
- assign( Patient,
Doctor∧¬Patient, PrimaryDoctor )
…
Revoke Rules
- revoke( Manager, true, Receptionist )
- revoke( Manager, true, Nurse )
…
Security Requirements
Designers have security properties in mind while
designing the set of assignment/revocation rules
• Availability properties
- A doctor must always be able to access patients’ record
• Escalation of privileges
- A receptionist cannot be granted doctors’ permissions
• Separation of duties
- A doctor cannot be also a receptionist
Role-reachability Problem
- availability
- separation of duties,
- escalation of privileges
-…
each reduces to
Role-reachability Problem
Can any user gain access to a given role goal
using the ARBAC rules?
Importance of Automated Analysis
• Monitoring strategies are not acceptable: denial-of-service
• Verification is essential
• Policies are difficult to inspect by hand: state space = O((2#roles) #users)
r1
r2
u1
1
0
u2
0
...
...
…
rn
… 0
0 … 1
... ... ...
configuration of the system
Assign/Revoke
actions
State-of-the-art
Reachability problem is
- PSPACE-complete [CSFW’06]
-fixed parameter tractable in # roles [CCS’07]
Restricted scenarios to tackle reachability
separate administration (limits expressiveness)
•
•
•
administrative roles and regular roles are disjoint
assignment/revocation admin roles is not allowed
allows to track only one user as opposed to tracking all users
[CCS’07]
under-approximation techniques (under separate administration)
error-finding (shallow errors)
not appropriate for correctness
[CCS’11]
State-of-the-art
(beyond separate administration)
Proving correctness
[Ferrara, Madhusudan, Parlato,
Security Analysis of RBAC through Program Verification – CSF’12]
Idea:
- simulate precisely the system with a program with integers
- each variable tracks the # of users in a role combination
- exponential # of variables
Over-approximation (effective)
- create a program that tracks only few role combinations
- analysis with Interproc with box domain
- scalable analysis (correctness)
- we cannot generate security attacks
Our Contribution
Achieving completeness and correctness without any
restriction
Fundamental Theorem : It is enough to track only k users at any time,
where k is the # of admin roles
- leads to a significant trimming procedure
(much smaller # of users, admin roles)
Novel Pruning technique : Transform the policy in a smaller one preserving
role-reachability
(effective also for separate administration)
Tool: VAC Verifier of Access Control
http://users.ecs.soton.ac.uk/gp4/VAC.html
Experiments on realistic policies from the literature
hospital, university, bank, and three suites of complex policies
Experimental Results
(hospital, university policies)
After Pruning
Policy
Hospital
University
Bank4
#roles #rules #admin #users #roles #rules #admin #users Time Reach
12
25
6
1092
3
5
2
9
0.3s No
12
25
6
1092
5
9
3
19
0.0s No
12
25
6
1092
3
5
2
9
0.0s Yes
12
25
6
1092
6
8
3
16
0.0s Yes
32
130
9
943
3
2
1
1
0.2s No
32
130
9
943
1
1
1
1
0.2s Yes
32
130
9
943
12
16
2
23
0.2s No
32
130
9
943
11
13
2
21
0.2s Yes
32
130
9
943
14
25
3
34
0.2s Yes
Complete analysis without separate admin restriction!
Experimental Results
After Pruning
First Suite
Size Policy
Time
#rules Time
#roles #rules #roles #rules
Second Suite
Third Suite
Time
#roles #rules
#rules Time
Time
#rules Time
#roles #rules
3
15
1
1
0.0s
3
5
0.0s
3
5
0.0s
5
25
1
1
0.0s
1
1
0.0s
1
1
0.0s
20
100
1
1
0.0s
11
26
0.0s
11
26
0.0s
40
200
1
1
0.0s
1
1
0.0s
1
1
0.1s
200
1000
1
1
0.1s
1
1
0.1s
1
1
0.1s
500
2500
1
1
0.1s
1
1
0.1s
1
1
0.2s
4k
20k
1
1
6.0s
1
1
6.0s
1
1
6.3s
20k
80k
1
1
3m24s
1
1
3m32s
1
1
3m20s
30k
120k
1
1
8m14s
1
1
8m33s
1
1
7m47s
40k
200k
1
1 14m50s
1
1
18m7s
1
1
21m1s
Complete analysis on complex policies!
only error-finding tools were successful
Experimental Results
After Pruning
Policy
#roles
#rules
#roles
#rules
Time
612
593
0
0
3s
612
593
2
1
3s
612
1186
2
1
3s
612
1186
0
0
2s
612
1779
0
0
2s
612
1779
2
1
2s
Bank3
612
2372
408
3285
0s
Bank4
612
2372
462
3272
0.1s
Bank1
Bank2
only error-finding tools were successful
Our Contribution
Achieving completeness and correctness without any
restriction
Fundamental Theorem : It is enough to track only k users at any time,
where k is the # of admin roles
- leads to a significant trimming procedure
(much smaller # of users, admin roles, roles)
Novel Pruning technique : Transform the policy in a smaller one preserving
role-reachability
(effective also for separate administration)
Tool: VAC Verifier of Access Control
http://users.ecs.soton.ac.uk/gp4/VAC.html
✔
Experiments on realistic policies from the literature
hospital, university, bank, and three suites of complex policies
Finite Model Property
Theorem:
The role-reachability problem can be solved by
tracking at most k+1 users
where k is the # of administrative roles
Idea of the proof 1/3
π=
c1
m1
c2
m2
… ci
mi
ci+1 …
cn
mn
Rule made
by Admini
ci=
cn+1
r1
r2
u1
1
0
u2
0
...
...
A user u is
•engaged if u’s configuration changes along the run
•essential if there is index i in which u is the only
user in Admini at configuration ci
…
rn
… 0
0 … 1
... ... ...
Idea of the proof 2/3
π=
c1
m1
c2
m2
Simplification rules
… ci
mi
ci+1 …
cn
mn
cn+1
Rule made
by Admini
•pick a non essential user u and remove all transitions changing u’s
configuration
•if all users are essential then
pick an engaged user and remove all transitions
changing u’s configuration after the last configuration
in which u is essential
… termination is guaranteed
Idea of the proof 3/3
π=
c1
m1
c2
m2
… ci
mi
ci+1 …
cn
For each 2 distinct engaged users u1 and u2
if
u1 is essential for role admin1 (the last time)
u2 is essential for role admin2 (the last time)
then admin1 ≠ admin2
There are at most k engaged users in the run π,
where k = # admin roles
mn
cn+1
Exploiting the Theorem
Can we track less users???
NO
Theoretically the k+1 bound is tight !!!
Heuristics???
REMOVE ADMIN ROLES
An admin role A is immaterial if there are more than k+1 users in role A.
Transform immaterial roles into regular ones.
REMOVE USERS
for each role-combination we need at most k+1 users.
Our Contribution
Achieving completeness and correctness without any
restriction
Fundamental Theorem : It is enough to track only k users at any time,
where k is the # of admin roles
- leads to a significant trimming procedure
(much smaller # of users, admin roles, roles)
✔
Novel Pruning technique : Transform the policy in a smaller one preserving
role-reachability
(effective also for separate administration)
Tool: VAC Verifier of Access Control
http://users.ecs.soton.ac.uk/gp4/VAC.html
✔
Experiments on realistic policies from the literature
hospital, university, bank, and three suites of complex policies
Our tool
Policy
role
pruning
CSF’12
TACAS’13
ad hoc-abstraction
boolean program encoding
integer program
model-checking
GetaFix
NO:
policy correct
Yes
error
interval-abstractions
using INTERPROC
NO:
policy correct
Yes:
may be a false error
Conclusions
&
Future work
Conclusions
- foundation of reasoning with ARBAC policies
(no separate administration)
- small model property:
tracking a bounded # of users suffices for role-reachability
- developed heuristics to effectively reduce
ARBAC systems on real-world policies.
- VAC : Verifier of Access Control
http://users.ecs.soton.ac.uk/gp4/VAC.html
Future Work
Automated analysis of access control policies
- Apply our techniques to systems supporting RBAC
- Microsoft SQL Servers, Microsoft Active Directory, SELinux, Oracle DBMS
- Extend our results to more expressive specs
(e.g., data leakage)
- Provide a counter-example guided abstraction scheme
- combine with over-approximation we developed (CSF’12)
Experimental Results (CSF’12)
After Pruning
Policy
Bank1
Bank2
Bank3
Bank4
#roles #actions #roles
#actions Time to INTERPROC Total
trasform time
time
34
593
26
535
7s
43s
50s
34
593
25
434
7s
44s
51s
68
1186
52
1070
9s
3m 0.2s
3m 11s
68
1186
50
868
9s
3m 0.3s
3m 12s
102
1779
78
1605
11s
7m 0.8s
7m 19s
102
1779
75
1302
10s
7m 08s
7m 18s
136
2372
104
2140
11s
13m 16s
13m 27s
136
2372
100
1736
9s
13m 15s
13m 24s
We can prove correctness!
only error-finding tools were successful
Our Contribution
Achieving completeness and correctness without any
restriction
Fundamental Theorem : It is enough to track only k users at any time,
where k is the # of admin roles
- leads to a significant trimming procedure
(much smaller # of users, admin roles, roles)
✔
Novel Pruning technique : Transform the policy in a smaller one preserving
role-reachability
(effective also for separate administration)
✔
Tool: VAC Verifier of Access Control
http://users.ecs.soton.ac.uk/gp4/VAC.html
✔
Experiments on realistic policies from the literature
hospital, university, bank, and three suites of complex policies