Policy Analysis for Self-administrated

Policy Analysis for Self-administrated

Role-based Access Control

Gennaro ParlatoU. Southampton, UK

Anna Lisa Ferrara P. MadhusudanU. Bristol, UK UIUC, USA

RBAC is an access control model - for large organization

- standard (NIST)

- supported by:

Microsoft SQL Servers, Microsoft Active Directory, SELinux, Oracle DBMS

Role-based Access Control(RBAC)

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 …

PA: (p1, Receptionist) (p2, Doctor) (p3, Doctor) …

UA: (Mary, Receptionist) (John, Doctor), (John, PrimaryD) (Jenny, Patient) (Tim, Doctor) …

• UA and PA relations may change by means of administrative rules:

• Assign(admin_role, precondition, target_role)

- if admin user A has admin_role, then A can assign any user u who satisfies precondition to target_role

• Revoke(admin_role, precondition, target_role)

Administrative RBAC (ARBAC)

Admins

UsersAdminActions

Users

Permissions

conjunction of literals over the set of Roles

Admins Roles

Roles

UA PA

Example of ARBAC Policy

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

Admins: Manager, Patient, Receptionist,…

Designers have security properties in mind while designing the set of assignment/revocation rules

Security Requirements

• 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

- …

Role-reachability Problem

each reduces to

Can any user gain access to a given role goal using the ARBAC rules?

Importance of Automated Analysis

1 0 0

0 0 1

r1 r2 rn

configuration of the system

Assign/Revoke actions

u1

u2... ...

…

……

...... ...

• Monitoring strategies are not acceptable: denial-of-service• Verification is essential• Policies are difficult to inspect by hand: state space = O((2#roles) #users)

State-of-the-artReachability 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

http://users.ecs.soton.ac.uk/gp4/VAC.html

Experimental Results(hospital, university policies)

12 25 6 1092

12 25 6 1092

12 25 6 1092

12 25 6 1092

32 130 9 943

32 130 9 943

32 130 9 943

32 130 9 943

32 130 9 943

#roles #admin#rules

After Pruning

Hospital

University

Bank4

Policy #users

Complete analysis without separate admin restriction!

0.3s No

0.0s No

0.0s Yes

0.0s Yes

0.2s No

0.2s Yes

0.2s No

0.2s Yes

0.2s Yes

Time Reach

3 5 2 9

5 9 3 19

3 5 2 9

6 8 3 16

3 2 1 1

1 1 1 1

12 16 2 23

11 13 2 21

14 25 3 34

#roles #admin #rules #users

Experimental Results

3 15

5 25

20 100

40 200

200 1000

500 2500

4k 20k

20k 80k

30k 120k

40k 200k

#roles #rules

After Pruning

Size Policy

Complete analysis on complex policies!

1 1 0.0s

1 1 0.0s

1 1 0.0s

1 1 0.0s

1 1 0.1s

1 1 0.1s

1 1 6.0s

1 1 3m24s

1 1 8m14s

1 1 14m50s

Time#rules#roles Time#rules

3 5 0.0s

1 1 0.0s

11 26 0.0s

1 1 0.0s

1 1 0.1s

1 1 0.1s

1 1 6.0s

1 1 3m32s

1 1 8m33s

1 1 18m7s


3 5 0.0s

1 1 0.0s

11 26 0.0s

1 1 0.1s

1 1 0.1s

1 1 0.2s

1 1 6.3s

1 1 3m20s

1 1 7m47s

1 1 21m1s


First Suite Second Suite Third Suite

only error-finding tools were successful

Experimental Results

612 593 0 0

612 593 2 1

612 1186 2 1

612 1186 0 0

612 1779 0 0

612 1779 2 1

612 2372 408 3285

612 2372 462 3272

3s

3s

3s

2s

2s

2s

0s

0.1s

#roles #roles#rules

Bank1

Bank2

Bank3

Bank4

Policy#rules Time

only error-finding tools were successful

After Pruning


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)




✔


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 c2… ci ci+1

m1m2 mi

Rule made

by Admini

cn cn+1

mn…

1 0 0

0 0 1

r1 r2 rn

u1

u2... ...

…

……

...... ...

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

ci=


π = c1 c2… ci ci+1

m1m2 mi

Rule made

by Admini

cn cn+1

mn…

Simplification rules •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


π = c1 c2… ci ci+1

m1m2 mi

cn cn+1

mn…

For each 2 distinct engaged users u1 and u2if 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

Exploiting the Theorem

Can we track less users??? NOTheoretically the k+1 bound is tight !!!

Heuristics???REMOVE ADMIN ROLESAn admin role A is immaterial if there are more than k+1 users in role A.

Transform immaterial roles into regular ones.

REMOVE USERSfor each role-combination we need at most k+1 users.






✔

✔


Our tool

interval-abstractions using INTERPROC

Policy role

NO:policy correct

Yes:may be a false error

integer program

ad hoc-abstraction

model-checking GetaFix

NO:policy correct

boolean program encoding

Yeserror

pruning

CSF’12TACAS’13

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

- developped

Apply our techniques to systems supporting RBAC - OS, Microsoft SQL Servers, Microsoft Active Directory, SELinux, Oracle DBMS

- Extend our results to more expressive specs

(e.g., info flow, data leakage)

- Provide a counter-example guided abstraction scheme

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)

34 593 26 535

34 593 25 434

68 1186 52 1070

68 1186 50 868

102 1779 78 1605

102 1779 75 1302

136 2372 104 2140

136 2372 100 1736

7s 43s 50s

7s 44s 51s

9s 3m 0.2s 3m 11s

9s 3m 0.3s 3m 12s

11s 7m 0.8s 7m 19s

10s 7m 08s 7m 18s

11s 13m 16s 13m 27s

9s 13m 15s 13m 24s

#roles #roles#actions Totaltime

INTERPROC

time

Bank1

Bank2

Bank3

Bank4

Policy #actions Time totrasform

We can prove correctness!only error-finding tools were successful

After Pruning






✔

✔

✔


Policy Analysis for Self-administrated

Documents

Transcript of Policy Analysis for Self-administrated