A Framework for Reflective Database Access Control Policies

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. 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. Introduction Bob Carol David Alice Database

4. View-Based Access Control

5. View-Based Access Control

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

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

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

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

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

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

12. Pitfalls in Reflective AC createorreplacefunction leakInfoFilter (p_schema varchar2, p_obj varchar2) returnvarchar2as begin for allowedVal in (select * from alice.employees) loop insertinto logtable values (sysdate, 'name:' || allowedVal.name || ', ssn:' || allowedVal.ssn || ', salary:' || allowedVal.salary); endloop; commit; return''; end;

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

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

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

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

17. 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).

18. 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).

19. 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(...).

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

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

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

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

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

25. Prototype Evaluation

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

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