270 likes | 362 Vues
Explore reflective database access control, its motivations, Oracle's VPD, formal modeling, Transaction Datalog, safety analysis, and pitfalls to avoid. Understand the importance of policy interactions, scalability challenges, and transaction management in this comprehensive framework.
E N D
A Framework for Reflective Database Access Control Policies Lars E. Olson, Carl A. Gunter, and P. Madhusudan University of Illinois at Urbana-Champaign
Outline • Motivation for Reflective Database Access Control • Oracle Virtual Private Database: A First Step • Formal Modeling for RDBAC • Transaction Datalog • Safety Analysis • Prototype Description
Introduction Bob Carol David Alice Database
View-Based Access Control Sales_Employees Bob Sales Sales Rep Carol Sales Manager
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”
Motivation • ACLs describe extent, rather than intent • Decision support data is often already in the database • Redundancy • Possibility of update anomalies
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?
Reflective Database Access Control Alice Database ? ACL Reflective Access Policy
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…
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;
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
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.
Transaction Datalog • Datalog extended with assertion and retraction semantics • Inference process extended to track modifications • Concurrency and atomicity • Implicit rollback on failure
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.
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).
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).
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(...).
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
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
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
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
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
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
Future Research Possibilities • Including retraction in formal analysis • State-independent security analysis • Negation semantics in TD • Atomic policies for updates • Optimizations