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

Database

Alice Bob Carol David

4

View-Based Access Control

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

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

Bob Sales

SalesCarol

Sales Rep

Manager

ACL

Bob

Carol

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?

Database

11

Database

Reflective Database Access Control

ACLReflective Access

Policy

?

Alice

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 ACcreate or replace function leakInfoFilter

(p_schema varchar2, p_obj varchar2)return varchar2 asbegin

for allowedVal in (select * from alice.employees) loopinsert 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 someone’s 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), 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

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

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 EvaluationQuery Database 1

(100 empl.)Database 2 (1000 empl.)

Baseline 0.42 ms 4.82 msTable owner 0.43 ms 4.84 msNon-manager access 0.44 ms 4.97 msManager access 0.66 ms 7.51 msAudit access 0.57 ms 6.01 msWithout Chinese Wall 0.12 ms 1.22 msChinese Wall 0.13 ms 1.43 msSecurity check, one user 1.67 ms 17.27 msSecurity 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