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
Employees Employees Employees Employees Employees
Name SSN Salary Dept Position
Alice 123456789 80000 HR CPA
Bob 234567890 70000 Sales Sales Rep
Carol 345678901 90000 Sales Manager
David 456789012 90000 HR Manager
ACL
Alice
David
5
View-Based Access Control
Employees Employees Employees Employees Employees
Name SSN Salary Dept Position
Alice 123456789 80000 HR CPA
Bob 234567890 70000 Sales Sales Rep
Carol 345678901 90000 Sales Manager
David 456789012 90000 HR Manager
6
View-Based Access Control
Sales_Employees
ACL
Bob
Carol
Bob
Sales
Sales Rep
Sales
Carol
Manager
7
VBAC Weaknesses
Employees Employees Employees Employees Employees
Name SSN Salary Dept Position
Alice 123456789 80000 HR CPA
Bob 234567890 70000 Sales Sales Rep
Carol 345678901 90000 Sales Manager
David 456789012 90000 HR Manager
Alice
123456789
80000
HR
CPA
Bob
234567890
70000
Sales
Sales Rep
Carol
345678901
90000
Sales
Manager
David
456789012
90000
HR
Manager
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
Motivation

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

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?

11
Reflective Database Access Control
Alice
Database
?




ACL
Reflective Access Policy
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
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
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
Pitfalls in Reflective AC

• Queries within policies must be executed under
  someones permissions.
• Cyclic policies cause infinite loop.
• Long chains of policies may use the database
  inefficiently.
• Determining safety is undecidable, in general.

16
Transaction Datalog

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

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
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), UserName.
• 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
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
Fixing the Leak

• Policies must always run under the definers
  privileges
• view.a(User, ...) - view.b(alice, ...),
  view.c(alice, ...).
• Basic table owner privileges can be generated
  automatically.
• view.a(alice, ...) - a(...).

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
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
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
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
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
Prototype Evaluation
Query Database 1 (100 empl.) Database 2 (1000 empl.)
Baseline 0.42 ms 4.82 ms
Table owner 0.43 ms 4.84 ms
Non-manager access 0.44 ms 4.97 ms
Manager access 0.66 ms 7.51 ms
Audit access 0.57 ms 6.01 ms
Without Chinese Wall 0.12 ms 1.22 ms
Chinese Wall 0.13 ms 1.43 ms
Security check, one user 1.67 ms 17.27 ms
Security check, all users 171.80 ms 17,390.00 ms
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
Future Research Possibilities

• Including retraction in formal analysis
• State-independent security analysis
• Negation semantics in TD
• Atomic policies for updates
• Optimizations