Presentation is loading. Please wait.

Presentation is loading. Please wait.

Implementing Reflective Access Control in SQL Lars E. Olson 1, Carl A. Gunter 1, William R. Cook 2, and Marianne Winslett 1 1 University of Illinois at.

Similar presentations


Presentation on theme: "Implementing Reflective Access Control in SQL Lars E. Olson 1, Carl A. Gunter 1, William R. Cook 2, and Marianne Winslett 1 1 University of Illinois at."— Presentation transcript:

1 Implementing Reflective Access Control in SQL Lars E. Olson 1, Carl A. Gunter 1, William R. Cook 2, and Marianne Winslett 1 1 University of Illinois at Urbana-Champaign 2 University of Texas

2 2 Outline Motivation for RDBAC Transaction Datalog ( TD ) as a Logical Basis and Policy Language Implementation Architecture and Description Evaluation

3 3 Introduction Database Alice BobCarolDavid

4 4 ACM-Based Access Control Employees NameSSNSalaryDeptPosition Alice12345678980000HRCPA Bob23456789070000SalesSales Rep Carol34567890190000SalesManager David45678901290000HRManager ACM Entries Alice David

5 5 ACM-Based Access Control Employees NameSSNSalaryDeptPosition Alice12345678980000HRCPA Bob23456789070000SalesSales Rep Carol34567890190000SalesManager David45678901290000HRManager

6 6 ACM-Based Access Control Sales_Employees BobSales Carol Sales Rep Manager ACM Entries Bob Carol

7 7 ACM Weaknesses Complicated policies can be awkward to define “Every employee can access their own records” “Every employee can view the name and position of every other employee in their department”

8 8 Motivation ACMs describe extent, rather than intent Decision support data is often already in the database – Redundancy – Possibility of update anomalies

9 9 Reflective Database Access Control Solution: access policies should contain queries – Not limited to read-only operations – Policies not assumed to be “omniscient” Is this a secure solution? (CCS ’08) Is this a practical solution? (DBSec ’09) Database

10 10 System Architecture Database TD Policy Individual User- defined Policies Policy Compiler SQL:1999 Recursive View Definitions Schema metadata User queries normally

11 11 Transaction Datalog Datalog extended with assertion and retraction semantics Inference process extended to track modifications Concurrency and atomicity Implicit rollback on failure

12 12 TD as a Policy Language Running example: restrict and audit sensitive accesses view.emp(User, Name, SSN, Salary, Dept, Pos) :- view.emp('alice', User, _, _, 'hr', _), view.emp('alice', Name, SSN, Salary, Dept, Pos), view.ins.auditLog('alice', User, Name, cur_time).

13 13 Compilation to SQL Views Off-the-shelf SQL databases benefit from years of query optimization research Datalog, SQL roughly equivalent – User ID provided by CURRENT_USER system variable – Recursion requires SQL:1999 Assertions and retractions – SQL syntax does not permit insert or delete within select statement – Execution ordering is significant

14 14 Side-Effects Within Queries Ideally, part of the language – Transaction control – Variable bindings In practice, executed as UDF – Execution ordering depends on query plan Executing UDF(s) last Forbids policies with mid-execution side-effects – Requires separate connection setup in DBs that do not support side-effects

15 15 Compilation Process (1 st Pass) view.emp(User, Name, SSN, Salary, Dept, Pos) :- view.emp('alice', User, _, _, 'hr', _), view.emp('alice', Name, SSN, Salary, Dept, Pos), view.ins.auditLog('alice', User, Name, cur_time). with view_emp as (... union all select e1.Name as User, e2.Name as Name,..., e2.Pos as Pos, 1 as Assert_flag, e1.Name as Assert_param1, e2.Name as Assert_param2 from view_emp e1, view_emp e2 where e1.Dept = 'hr' and e1.Name = 'alice' and e2.Name = 'alice' union all...) select distinct User, Name,..., Pos from view_emp where Assert_flag = 1 and assert_auditLog(Assert_param1, Assert_param2) != 0 function assert_auditLog (@User varchar, @Name varchar)... Schema: User, Name, SSN, Salary, Dept, Pos, Assert_flag, Assert_param1, Assert_param2

16 16 Compilation Process (2 nd Pass) function assert_auditLog (@User varchar, @Name varchar)... with view_emp as (... union all select e1.Name as User, e2.Name as Name,..., e2.Pos as Pos, 1 as Assert_flag, e1.Name as Assert_param1, e2.Name as Assert_param2 from view_emp e1, view_emp e2 where e1.Dept = 'hr' and e1.Name = 'alice' and e2.Name = 'alice' union all...) select distinct User, Name,..., Pos from view_emp where Assert_flag = 1 and assert_auditLog(Assert_param1, Assert_param2) != 0 Schema: User, Name, SSN, Salary, Dept, Pos, Assert_flag, Assert_param1, Assert_param2 view.emp(User, Name, SSN, Salary, Dept, Pos) :- view.emp('alice', User, _, _, 'hr', _), view.emp('alice', Name, SSN, Salary, Dept, Pos), view.ins.auditLog('alice', User, Name, cur_time).

17 17 Compilation Process (cont.) Filter on user: create view view_emp_public as select Name,..., Pos from view_emp where User = CURRENT_USER; grant select on view_emp_public to public;

18 18 Optimizations Recursive views are expensive! Use predicate unfolding view.emp('alice', Name, SSN, Salary, Dept, Pos) :- emp(Name, SSN, Salary, Dept, Pos). …allows us to rewrite view.emp('alice', User, _, _, 'hr', _) …to emp(User, _, _, 'hr', _)

19 19 Optimizations (cont.) union all is expensive (although not as bad as recursion) – Build query dynamically – Pre-compute portions of rule – If rule doesn’t apply, we can eliminate a union – Simulated with stored procedure

20 20 Evaluation Baseline – Custom-defined views – ACM-based enforcement – Two baselines for side-effect queries No side-effect Side-effect UDF called within view Compiled views – Unoptimized, with recursion – Optimized with predicate unfolding Simulated optimization with predicate unfolding and union all elimination

21 21 Timing Results (fixed DB size)

22 22 Timing Results (fixed query)

23 23 Future Research Possibilities Further DB integration – Automatic checks for safety – Implementation of pre-computing optimization Improvements to TD – Aggregation – Negation – Atomic update policies

24 24 Work on RDBAC Olson, Gunter, Madhusudan, “A Framework for Reflective Database Access Control Policies,” CCS 2008A Framework for Reflective Database Access Control Policies Under review: case study for medical database, formal policy analysis Research lab web page: http://seclab.uiuc.edu/ http://seclab.uiuc.edu/

25 25 Related Work Bonner, “Transaction Datalog: A Compositional Language for Transaction Programming,” LNCS 1998Transaction Datalog: A Compositional Language for Transaction Programming Oracle Corporation, “Oracle Virtual Private Database,” Technical report, 2005Oracle Virtual Private Database Draxler, “Accessing Relational and Higher Databases Through Database Set Predicates in Logic Programming Languages,” PhD thesis, Zürich University, 1991Accessing Relational and Higher Databases Through Database Set Predicates in Logic Programming Languages Bossi, Cocco, Dulli, “A Method for Specializing Logic Programs,” TOPLAS 1990A Method for Specializing Logic Programs

26 26 Conclusion RDBAC allows more robust access control. Compilation of TD rules to SQL views implements RDBAC with current database technology. Performance cost of compiled views is low and can yet be improved.

27 27 Timing Results (fixed DB size and query)

28 28 Timing Results– Franchise Scenario (fixed DB size)


Download ppt "Implementing Reflective Access Control in SQL Lars E. Olson 1, Carl A. Gunter 1, William R. Cook 2, and Marianne Winslett 1 1 University of Illinois at."

Similar presentations


Ads by Google