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
2
Introduction
Alice
Bob
Carol
David
Database
3
View-Based Access Control
Employees
Name
SSN
Salary
Dept
Position
ACL
Alice
123456789
80000
HR
CPA
Bob
234567890
70000
Sales
Sales Rep
Carol
345678901
90000
Sales
Manager
David
456789012
90000
HR
Manager
Alice
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
5
View-Based Access Control
Sales_Employees
ACL
Bob
Bob
Sales
Sales Rep
Carol
Carol
Sales
Manager
6
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
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
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
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;
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)?
changeSalary(alice, 80000, 100000)?
No.
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
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
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
28