April 6, 2009 1

Redundancy and Information Leakage in Fine Grained Access Control

Govind Kabra (Univ of Illinois, Urbana-Champaign)

Ravi Ramamurthy (Microsoft Research)

S. Sudarshan (IIT Bombay)

Modified for the course by:Adil Anis Sandalwala

April 6, 2009 2

Fine Grained Access Control SQL authorization at the level of

table/column e.g. grant select on employee(name) to public

Fine-grained access control examples Managers can see records of their employees Faculty has access to grades of courses they

taught

Application-layer support for FGA Several Limitations.

Database support for FGA Validity checking model View replacement model

User A

User B

User C

April 6, 2009 3

Based on rewriting of queryCreate authorization view RA In user query, replace R by RA

Auth view authL: customers can see the lineitems only for their orders

Several proposals Oracle VPD, Sybase row level security LeFevre et al. [VLDB04], Agrawal et al. [ICDE05]

Key implementation issues Redundancy in rewritten queries Information leakage through UDFs, timing analysis, exceptions

View Replacement model for FGA

User Query:select * from lineitemwhere shipmode=‘express’

σ

L

σ

authL σ

O

σ

L

Agenda

Motivation Previous work Redundancy Removal Information Leakage

What plans can be guaranteed to not leak information. Techniques to find optimal best plans.

Integrating RR and safety. Conclusion

April 6, 2009 4

Previous work

Oracle’s Virtual Private database(VPD) Supports FGA through functions associated with each

relation which return strings of predicates. Cell level access control (LeFevre et al.)

Replace unauthorized values with null. Two classification of models:

Truman Models: Uses query rewriting. Non-Truman Models: A query is valid if it can be

rewritten with authorized views. Invalid queries are rejected.

April 6, 2009 5

Query Rewriting Model

April 6, 2009 6

An authorized ViewCREATE VIEW auth_Ri AS

SELECT Li FROM Ri WHERE Pi

Li contains expressions implementing cell level access-control

Pi has the authorization predicates (may have sub-queries)

Such authorized views are represented as:Ri Ai

where Ai is an expression containing the sub-queries in Pi.

Selection conditions in Pi are folded into semi-join condition θi

For simplicity, from now on we assume Li to be *

Thus a query of the form:R1 R2 …. Rn (R1 A1) (R2 A2) …

θi

θ1 θ2

April 6, 2009 7

Redundancy Removal

Most queries access only authorized data

April 6, 2009 8

Auth view authL: Customers can see lineitems only for their own orders

Query: Customer 123 wants to see details of lineitems shipped using express mode only for his orders

Select * from lineitem L, orders O

where l_orderkey = o_orderkey

and o_custkey=123

and l_shipmode=‘express’

The semi-join check is redundant !!!

Redundancy between queries and authorization predicates

σ

O

σ

L

σ

O

σ

authL

σ

O

σ

O

σ

L

April 6, 2009 9

In general, RR is equivalent to query minimization

Heuristic approach: eliminate redundant semi-joins If E2 subsumes E1, then transform E1 E2 to E1

Added transformation rules in a rule based optimizer Use materialized view matching support for testing subsumptions

Redundancy detection and removal-I

σ

O

σ

O

σ

L Apply RRσ

O

σ

L

E1 E2

Redundancy detection and removal-II Subsumption Test

E1 is subsumed by E2 in E1 E2 if The predicates in selection of E2 are weaker than corresponding predicates

in E1 The semi-join condition in equates the columns of E1 and E2 that are

equivalent under the mapping.

Rule to detect and remove redundancy: If E2 subsumes E1 then replace E1 E2 by E1 In case of disjunction of sub-query expression:

Apply subsumption test to each disjunct If any one is found to subsume E1, then discard the complete set of semi-joins.

Consider the query:select * from E1 where (A in (select….)) OR (B in (select…..))

April 6, 2009 10

θi

θi

θi

Redundancy detection and removal-III Consider a rewritten query:

(R1 A1) (R2 A2) ……... (Rn An)

Rules applied at: Transformation Phase:

Explores all possibilities of detecting redundancy Inefficient.

Simplification Phase : Normalized form by pulling up semi-joins. Linear number of authorization checks Depends on order of Ai’s Easy to integrate with existing optimizers.

April 6, 2009 11

θ1 θ2 θ1

April 6, 2009 12

TPC-H Benchmark Queries, with authorization checks

Comparing normalized execution times

Performance benefits of RR

TPCH Query Execution Time Without RR

Execution Time With RR

Query 3 100.00 48.28

Query 6 56.03 38.79

Query 10 94.83 55.45

Query 12 77.57 43.97

Query 14 49.14 38.79

April 6, 2009 13

Information Leakage

So you thought only the query result matters?

April 6, 2009 14

Auth view myemployee: only those employee whose dept_id is in A1

Query:

select * from employee where myudf(salary)

Final query plan is not safe UDF may be pushed down in plan, and executed on

unauthorized intermediate result As a side-effect, UDF may expose values passed to it [Litchfield]

Information Leakage via UDFs

σmyudf(E.salary)

myemployees

σmyudf(E.salary)

employees A1

σmyudf(E.salary)

employees

A1

April 6, 2009 15

Exceptions Query: select * from employee

where 1/(salary-100K) = 0.23 Query plan: Selection condition in query gets pushed below

authorization semi-join Divide by zero exception if salary = 100K Reveals that employee has salary = 100K

Error Messages to_Integer function may throw error revealing the content

Timing Analysis Sub-query can perform an expensive computation only if certain

tuples are present in its input.

Can be partly solved using sandboxing

Other channels of information leakage

April 6, 2009 16

UDFonTop: Keep UDFs at the top of query plan Definitely safe, no information leakage Better plans possible if UDF is selective

Optimal Safe plan When is a plan safe? How to search for optimal plan amongst alternative safe plans?

Preventing Information Leakage via UDFs

σmyudf(E.salary)

employees

A1

σmyudf(E.salary)

employees A1

April 6, 2009 17

Safe plans w.r.t. UDFs Approach 1: If UDF uses attributes from R, apply

authorization checks for R before UDF Not sufficient; Full expression must be authorized Expression that can be rewritten using authorized views [RMSR04] How to efficiently infer which expressions are authorized?

Auth Views: employee, (medical-record A2) Query: Find names of all employee having AIDS

σudf2(E.name)

σM.disease=‘AIDS’

medical-record A2

σudf2(E.name)

employees σM.disease=‘AIDS’

medical-record

A2

σudf2(E.name)

employees

σM.disease=‘AIDS’

medical-record

A2

employees

Some definitions Authorized Expression

An expression is authorized if it is equivalent to an expression defined using only authorized views.

Safety w.r.t. USF’s

A node in a query plan is safe w.r.t. USF’s if: There are no USF’s in the node, and all inputs (if any) of the

node are all safe, or The node has a USF, it is not an apply operator, and all its

inputs are safe and authorized. The node is an apply operator, both its children are safe and

either Right child does not have any USF invocations, or The left child is authorized

April 6, 2009 18

April 6, 2009 19

Framework of rule based optimizer

σ

employees

medical-records

Q1

G4

G2

G3

σemployees

medical-records

Q1

G1

G5

G6

G7

G4

G2

G3

σemployees

medical-records

Q1

G5

G6

G1

April 6, 2009 20

Inferring authorization of expressions Authorization as a logical property of group

Start with the rewritten query:

Mark groups containing original authorization views as authorized

Rule IA: If all the children group nodes of an operation node are authorized, the parent-group-node of that operation node are also marked as authorized.

Propagate authorization upwards to the parent groups A node which is not authorized initially may be inferred as

authorized later. This information must be propagated to the parents of the node

April 6, 2009 21

Inferring authorization of expressions Authorization as a logical property of group

Start with the rewritten query:

Mark groups containing original authorization views as authorized

Propagate authorization upwards to the parent groups

σ

employees

medical-records

Q1

G4

G2

G3

σemployees

medical-records

Q1

G1

G5

G6

G7

G4

G2

G3

σemployees

medical-records

Q1

G5

G6

G1

G5

G1

G6

G5G7

G1 G4

G2

G6

G3

σemployees

medical-records

Q1

April 6, 2009 22

Extending optimizer to find optimal safe plan

There are two approaches to find the optimal safe plan:

Only Safe Transformations Allow UDF push-down/pull-up only on top of authorized expressions Only safe alternatives are present in memo, pick the optimal plan

Pick Safe Plan Allow all transformations for UDF Use “required/derived feature” to pick only plans where UDF are on

top of authorized expression

Both RR and Optimal Safe Plan are necessary: Motivation

No RR With RR

UDF on top 100 47.83

Safe Optimal 53.25 23.25

April 6, 2009 23

Comparing normalized execution times.

April 6, 2009 24

Integrating RR and Optimal safe plan Rule-based optimizers involve a simplification phase

followed by a transformation phase RR in simplification reduces query size and optimization time

But RR in simplification interferes with safety inference Optimal safe plan generation requires preserving

the following input plan until memo is created

RR can possibly remove some Ai

Possible integration: RR in transformation phase RR in simplification phase with conditioned authorization for safe

plan generation

RR during Transformation Phase

Introduce authorization-anchor nodes These prevent transformations that pull-up Ri or Ai’s or push

down any operation into the semi-join

At start of transformation, we remove these nodes perform authorization propagation.

Then RR rules are applied.

Disadvantage: Increased optimization time due to multiple redundancy checks of

semi-joins.

April 6, 2009 25

RR in simplification phase with conditioned authorization Instead of marking an expression authorized, we mark it

as conditioned-authorized. For eg.: we have a relation Ri with authorization Ai

Ai could be removed/ moved elsewhere by Ri So we mark Ri as authorized condition on Ai

Ie. Conditioned on it being semi-join/joined with Ai

If simplification results in a empty condition, we can infer that the expression is unconditionally authorized.

For a group: If any of the child is unconditionally authorized, so is the group.

If expression E is of the form E1 E2, where E1 is authorized conditioned on A1 and E2 is equivalent to Bj Ai, then We infer that resultant expression is unconditionally authorized.

April 6, 2009 26

Rule for propagation authorization The extended propagation rule is:

If operation has two groups E1 and E2 each authorized on A1 and A2 resp., then result is authorized conditioned on A1 and A2

If A1 subsumes E2, we drop A1 from the condition.

April 6, 2009 27

Handling Exceptions and Error Messages

For each built-in function, we create a safe version of the function that ignores exceptions and does not output error.

Predicates using USF’s are rewritten using the corresponding safe version.

We can create a safe version of division function, which catches exception and returns a null value.

for the predicate (1/(salary-100K)==0.2) we can use this safety predicate. This may allow unauthorized tuples to pass through. However,

we can write a such that it is weaker than the original condition.

We can push down the safe predicates while retaining the unsafe version on top.

April 6, 2009 28

April 6, 2009 29

Performance Evaluation

Study utility of RR and Optimal Safe Plan Auth: Managers can see information only pertinent to

their region authNation: Nation ( (Region)) authCustomer: Customer (Nation ( (Region))) …

Query: Find supplier who fulfill “important” orders

AuthorizationView replacement

σσ

April 6, 2009 30

Both RR and Optimal Safe Plan are necessary

No RR With RR

UDF On

Top

Safe Optimal

Safe Optimal

UDF On Top

No RR

Apply RR

Apply Both

47.83

23.25

100.00

53.25

April 6, 2009 31

Conclusions Redundancy in queries

Transformation rules for redundancy removal

Information leakage Definition of a safe plan Extending optimizer for generating optimal safe plan

Preliminary performance study of proposed techniques Ensure safety while providing significant performance benefits

Future: Study conditioned authorization to reduce optimization time Better solution for timing analysis based information leakage Add rules for handling authorizations involving nullification and

aggregation

Thank You!!

Questions????

April 6, 2009 32