Policy Analysis for Self-administrated Role-based Access Control Gennaro Parlato U. Southampton, UK Anna Lisa Ferrara P. Madhusudan U. 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 RolesPermissions Permissions are pairs (object, operation) UA = Users X Roles PA = Roles X Permissions

RBAC Example: Hospital Roles: Doctor, Manager, Nurse, Patient, PrimaryD, Receptionist,… Permissions: p 1 = Create_Appointment p 2 = View_OldMedicalRecord p 3 = View_RecentMedicalRecords … PA: (p 1, Receptionist) (p 2, Doctor) (p 3, 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 Users Admin Actions 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 r 1 r 2 rnrn configuration of the system Assign/Revoke actions u1u1 u2u … … … 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-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: V AC Verifier of Access Control Experiments on realistic policies from the literature hospital, university, bank, and three suites of complex policies

Experimental Results (hospital, university policies) #roles #admin #rules After Pruning Hospital University Bank 4 Policy #users Complete analysis without separate admin restriction! 0.3sNo 0.0sNo 0.0sYes 0.0sYes 0.2sNo 0.2sYes 0.2sNo 0.2sYes 0.2sYes Time Reach #roles #admin #rules #users

Experimental Results k20k 80k 30k120k 40k200k #roles #rules After Pruning Size Policy Complete analysis on complex policies! 110.0s s s 113m24s 118m14s 1114m50s Time #rules #roles Time #rules 350.0s s s s 113m32s 118m33s 1118m7s Time #rules #roles Time #rules 350.0s s 110.1s s 116.3s 113m20s 117m47s 1121m1s Time #rules #roles Time #rules First Suite Second SuiteThird Suite only error-finding tools were successful

Experimental Results s 2s 0s 0.1s #roles #rules Bank 1 Bank 2 Bank 3 Bank 4 Policy #rules Time only error-finding tools were successful After Pruning

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: V AC Verifier of Access Control 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 π = c1c1 c2c2 … cici c i+1 m1m1 m2m2 mimi Rule made by Admin i cncn c n+1 mnmn … r 1 r 2 rnrn u1u1 u2u … … … 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 Admin i at configuration c i ci=ci=

Idea of the proof 2/3 π = c1c1 c2c2 … cici c i+1 m1m1 m2m2 mimi Rule made by Admin i cncn c n+1 mnmn … 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

Idea of the proof 3/3 π = c1c1 c2c2 … cici c i+1 m1m1 m2m2 mimi cncn c n+1 mnmn … 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

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: V AC Verifier of Access Control Experiments on realistic policies from the literature hospital, university, bank, and three suites of complex policies ✔ ✔

Our tool interval-abstractions using INTERPROC Policyrole NO: policy correct Yes: may be a false error integer program ad hoc-abstraction model-checking GetaFix NO: policy correct boolean program encoding Yes error pruning CSF’12 TACAS’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 - 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) s43s50s 7s44s51s 9s3m 0.2s3m 11s 9s3m 0.3s3m 12s 11s7m 0.8s7m 19s 10s7m 08s7m 18s 11s13m 16s13m 27s 9s13m 15s13m 24s #roles #actions Total time INTERPROC time Bank 1 Bank 2 Bank 3 Bank 4 Policy #actions Time to trasform We can prove correctness! only error-finding tools were successful After Pruning

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: V AC Verifier of Access Control Experiments on realistic policies from the literature hospital, university, bank, and three suites of complex policies ✔ ✔ ✔

State-of-the-art Experiments Standardized realistic set of benchmarks - hospital policy - university policy - bank policy - three suites of complex policies complete analysis under sep. admin. error-finding only (shallow errors)