1 / 86

Policy Analysis for Self-administrated

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

boyce
Download Presentation

Policy Analysis for Self-administrated

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Policy Analysis for Self-administrated Role-based Access Control Gennaro Parlato U. Southampton, UK Anna Lisa Ferrara P. Madhusudan U. Bristol, UKUIUC, USA

  2. Role-based Access Control (RBAC) RBACis 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

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

  4. 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) Roles Permissions Users Admin Actions Admins Admins Roles PA UA Users conjunction of literals over the set of Roles

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

  6. 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

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

  8. 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) … … … . . . . . . . . . . . . . . . configuration of the system Assign/Revoke actions

  9. State-of-the-art • Reachability problem is • - PSPACE-complete [CSFW’06] • fixed parameter tractable in # roles [CCS’07] • Restrictedscenarios 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]

  10. 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

  11. 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

  12. Experimental Results (hospital, university policies) After Pruning #users #rules #roles #users #admin Reach #roles Time #rules #admin Policy Hospital University Bank4 Complete analysis without separate admin restriction!

  13. Experimental Results After Pruning Second Suite Third Suite First Suite Size Policy Time Time Time #rules #roles #rules #rules #roles #rules #roles #roles Time Time Time #rules #rules #rules Complete analysis on complex policies! only error-finding tools were successful

  14. Experimental Results After Pruning #rules #roles #rules #roles Time Policy Bank1 Bank2 Bank3 Bank4 only error-finding tools were successful

  15. 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 ✔

  16. 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

  17. Idea of the proof 1/3 mn mi m2 m1 … … cn+1 cn ci+1 c2 ci c1 π = Rule made by Admini … … ci= … . . . . . . . . . . . . . . . • 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

  18. Idea of the proof 2/3 mn mi m2 m1 … … cn+1 cn ci+1 c2 ci c1 π = Rule made by Admini • 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

  19. Idea of the proof 3/3 mn mi m2 m1 … … cn+1 cn ci+1 c2 ci c1 π = 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

  20. 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.

  21. 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 ✔ ✔

  22. Our tool Policy role pruning CSF’12 TACAS’13 ad hoc-abstraction boolean program encoding integer program model-checking GetaFix interval-abstractions using INTERPROC Yes error NO: policy correct NO: policy correct Yes: may be a false error

  23. Conclusions & Future work

  24. 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

More Related