Reflective Database Access Control

1
Reflective Database Access Control

• Lars Olson
• Ph.D. Thesis Defense

2
Introduction
Bob
Carol
David
Alice
Database








3
ACM-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
ACM Entries
Alice
David
4
ACM-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
5
ACM-Based Access Control
Sales_Employees
ACM Entries
Bob
Carol
Bob
Sales
Sales Rep
Sales
Carol
Manager
6
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

7
Motivation

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

8
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)
• What is it useful for? (SPIMACS 09)

9
Thesis Statement
Datalog-based reflective database access control
can provide a flexible, scalable, and efficient
mechanism for defining, enforcing, and formally
reasoning about fine-grained access control
policies.
10
Outline

• Challenges for RDBAC
• Theory
• Formalism using Transaction Datalog
• Security analysis
• Implementation
• Prototype description
• Evaluation
• Case Studies
• Medical database
• Building automation system
• Future Work and Conclusion

11
Outline

• Challenges for RDBAC
• Theory
• Formalism using Transaction Datalog
• Security analysis
• Implementation
• Prototype description
• Evaluation
• Case Studies
• Medical database
• Building automation system
• Future Work and Conclusion

12
Application-Layer Security
Application A Access Control Rules
User a
Database
A
User b
User c
13
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

14
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

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

17
Desirable Properties

• Policy can depend on user attributes or object
  attributes in database
• Updates immediately affect policy evaluation
• Policies are fine-grained
• Policies may modify database
• Lower-privileged users may define privileges for
  their own tables (non-omniscient policies)
• Model has formal mathematical basis
• System performance is comparable to current
  technology

18
Outline

• Challenges for RDBAC
• Theory
• Formalism using Transaction Datalog
• Security analysis
• Implementation
• Prototype description
• Evaluation
• Case Studies
• Medical database
• Building automation system
• Future Work and Conclusion

19
Transaction Datalog

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

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

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

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

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

24
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

25
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

26
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

27
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

28
Outline

• Challenges for RDBAC
• Theory
• Formalism using Transaction Datalog
• Security analysis
• Implementation
• Prototype description
• Evaluation
• Case Studies
• Medical database
• Building automation system
• Future Work and Conclusion

29
System Architecture
Individual User-defined Policies
TD Policy
Policy Compiler
Schema metadata
SQL1999 Recursive View Definitions
Database
User queries normally
30
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 SQL1999
• Assertions and retractions
• SQL syntax does not permit insert or delete
  within select statement
• Execution ordering is significant

31
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

32
Compilation Process (1st 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
0 or (Assert_flag 1 and assert_auditLog(Assert_p
aram1, Assert_param2) ! 0)
function assert_auditLog (_at_User varchar, _at_Name
varchar) ...
Schema User, Name, SSN, Salary, Dept,
Pos, Assert_flag, Assert_param1, Assert_param2
33
Compilation Process (2nd 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).
function assert_auditLog (_at_User varchar, _at_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
0 or (Assert_flag 1 and assert_auditLog(Assert_p
aram1, Assert_param2) ! 0)
Schema User, Name, SSN, Salary, Dept,
Pos, Assert_flag, Assert_param1, Assert_param2
34
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
35
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', _)

36
Optimizations (cont.)

• union all is expensive (although not as bad as
  recursion)
• Build query dynamically
• Pre-compute portions of rule
• If rule doesnt apply, we can eliminate a union
• Simulated with stored procedure

37
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

38
Timing Results (fixed DB size)
39
Timing Results (fixed query)
40
Outline

• Challenges for RDBAC
• Theory
• Formalism using Transaction Datalog
• Security analysis
• Implementation
• Prototype description
• Evaluation
• Case Studies
• Medical database
• Building automation system
• Future Work and Conclusion

41
Case Study Medical Database

• HIPAA legislation
• Protects privacy of patients
• Access to electronic health records must be
  restricted based on the specific roles of the
  members of their workforce.
• Idealism meets reality emergencies are common
• Commonly implemented by Honor System, e.g. sign a
  form yearly

42
Example Policies

• Patients may view their own medical data
• Primary care physicians may view their own
  patients data
• Caregivers assigned to consult with a patient may
  view that patients data
• Current employees may access any patients
  record, but an audit record is generated

43
Formal Security Analysis

• No untrusted user can ever gain access to a
  patients lab results.
• Uses upper-bound estimate on append-only policies
• Rules with retractions, rules not safely
  rewritable omitted
• Sample database populated, verified with Prolog
• Omitted rules analyzed manually
• Analysis scalability
• Running time A increased patients doctors
• Running time B increated patients only

44
Formal Security Analysis
45
Case Study Building Automation System
46
Example Policies

• Users who are given delegation privileges over a
  room may add or delete users that may access the
  room
• Students enrolled in a class may unlock the room
  where the class occurs during normal class hours
• Attendance recorded
• Internet access disabled
• Anyone may purchase items from a vending machine,
  with cost of items deducted from their account

47
Outline

• Challenges for RDBAC
• Theory
• Formalism using Transaction Datalog
• Security analysis
• Implementation
• Prototype description
• Evaluation
• Case Studies
• Medical database
• Building automation system
• Future Work and Conclusion

48
Future Research Possibilities

• Improvements to TD
• Aggregation
• Negation
• Atomic policies for updates
• Improvements to analysis
• Retraction analysis
• State-independent analysis
• Information flow using delegated privileges

49
Future Research Possibilities

• Further DB integration
• Automatic checks for safety
• Pre-computing optimization
• Side-effects and ordering
• Development of Case Studies
• Discretionary access to patient records
• Trusted users no longer constant
• Specifying exceptions
• Firewall rules

50
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

51
Conclusion

• 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.
• RDBAC provides benefits for real-world scenarios.