1. A Framework for Reflective Database Access Control Policies Lars E. Olson, Carl A. Gunter, and P. Madhusudan University of Illinois at Urbana-Champaign

2. 2 Outline Motivation for Reflective Database Access Control Oracle Virtual Private Database: A First Step Formal Modeling for RDBAC –Transaction Datalog –Safety Analysis Prototype Description

3. 3 Introduction Database Alice BobCarolDavid

4. 4 View-Based Access Control Employees NameSSNSalaryDeptPosition Alice12345678980000HRCPA Bob23456789070000SalesSales Rep Carol34567890190000SalesManager David45678901290000HRManager ACL Alice David

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

6. 6 View-Based Access Control Sales_Employees BobSales Carol Sales Rep Manager ACL Bob Carol

7. 7 VBAC Weaknesses Employees NameSSNSalaryDeptPosition Alice12345678980000HRCPA Bob23456789070000SalesSales Rep Carol34567890190000SalesManager David45678901290000HRManager Alice Bob Carol David456789012 345678901 234567890 12345678980000 70000 90000 HR Sales HRManager Sales Rep CPA

8. 8 VBAC 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”

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

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

11. 11 Database Reflective Database Access Control ACL Reflective Access Policy ? Alice

12. 12 Oracle Virtual Private Database User-defined function as query filter –Access to current user –Access to other table data (excluding current table) –Non-omniscient— subject to policies protecting other data Flexible— a little too flexible…

13. 13 Pitfalls in Reflective AC create or replace function leakInfoFilter (p_schema varchar2, p_obj varchar2) return varchar2 as begin for allowedVal in (select * from alice.employees) loop insert into logtable values (sysdate, 'name:' || allowedVal.name || ', ssn:' || allowedVal.ssn || ', salary:' || allowedVal.salary); end loop; commit; return ''; end;

14. 14 Not Necessarily a Problem Note: –Only privileged users can define VPD policies. –Using POLICY_INVOKER instead of SESSION_USER in the employees table would solve this problem. Still, centralized policy definers not ideal –Scalability –Difficulty in understanding subtle policy interactions …and you have to deal with surly DB admins

15. 15 Pitfalls in Reflective AC Queries within policies must be executed under someone’s permissions. Cyclic policies cause infinite loop. Long chains of policies may use the database inefficiently. Determining safety is undecidable, in general.

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

17. 17 Transaction Datalog Example State: emp(alice, 1234, 80000, hr, manager). emp(bob, 2345, 60000, hr, accountant). Transaction Base: changeSalary(Name, OldSalary, NewSalary) :- emp(Name, SSN, OldSalary, Dept, Pos), del.emp(Name, SSN, OldSalary, Dept, Pos), ins.emp(Name, SSN, NewSalary, Dept, Pos). Runtime queries: changeSalary(alice, 50000, 100000)? No. changeSalary(alice, 80000, 100000)? Yes.

18. 18 TD as a Policy Language Allow users to access their own records: view.emp(User, Name, SSN, Salary, Dept, Pos) :- emp(Name, SSN, Salary, Dept, Pos), User=Name. Allow users to view names of employees in their own department: view.emp(User, Name, null, null, Dept, Pos) :- emp(User, _, _, Dept, _), emp(Name, _, _, Dept, Pos).

19. 19 TD as a Policy Language Restrict and audit sensitive accesses: view.emp(User, Name, SSN, Salary, Dept, Pos) :- emp(User, _, _, hr, _), emp(Name, SSN, Salary, Dept, Pos), ins.auditLog(User, Name, cur_time). Chinese Wall policy: view.bank1(User, Data1, Data2) :- cwUsers(User, 1, OldValue), bank1(Data1, Data2), del.cwUsers(User, 1, OldValue), ins.cwUsers(User, 1, 0).

20. 20 Fixing the Leak Policies must always run under the definer’s privileges: view.a(User,...) :- view.b(alice,...), view.c(alice,...). Basic table owner privileges can be generated automatically. view.a(alice,...) :- a(...).

21. 21 Formal Safety Analysis Efficiency of answering the question “Can user u ever gain access right r to object o ?” –Excludes actions taken by trusted users TD can implement HRU model Consequence: safety is undecidable in general

22. 22 Decidable Class #1 Read-only policies Check whether subject s can access object o initially Ignore irrelevant tables Infrequent updates –Polynomial-time safety check –Unsafe configurations can be rolled back

23. 23 Decidable Class #2 Retraction-free “Safe rewritability” –Rewrite policies to calculate their effect on the database, e.g.: Original policy rule: p(X) :- q(X, Y), ins.r(X, Y), s(Y, Z). Rewritten rules: r(X, Y) :- q(X, Y). p(X) :- q(X, Y), r(X, Y), s(Y, Z). –Rewritten rules must be range-restricted to ensure efficient computation

24. 24 Proving Safety Decidability Database never shrinks Rewritten rules provide upper bound on database Every sequence of operations reaches fixed point Finitely many operations Too ugly? –Use upper bound as conservative estimate –No negation semantics in TD

25. 25 Proof-of-Concept Prototype SWI-Prolog Memory-resident database state Evaluated queries: –Baseline: direct table access –Table owner –View record of self –Manager access of all employees in the department –Audit access –Chinese Wall Calculated safety check (Class #1) for one user, all users Scalability with increased database size and number of users

26. 26 Prototype Evaluation QueryDatabase 1 (100 empl.) Database 2 (1000 empl.) Baseline0.42 ms4.82 ms Table owner0.43 ms4.84 ms Non-manager access0.44 ms4.97 ms Manager access0.66 ms7.51 ms Audit access0.57 ms6.01 ms Without Chinese Wall0.12 ms1.22 ms Chinese Wall0.13 ms1.43 ms Security check, one user1.67 ms17.27 ms Security check, all users171.80 ms17,390.00 ms

27. 27 Conclusion Reflective Database Access Control is a more flexible model than View-Based Access Control. –Easier to model policy intent –Subtle data interactions create new dangers Transaction Datalog provides a reasonable theoretical basis for RDBAC. –Expressive semantics for describing policy intent –Safety analysis

28. 28 Future Research Possibilities Including retraction in formal analysis State-independent security analysis Negation semantics in TD Atomic policies for updates Optimizations