1. April 6, 20091 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

2. April 6, 20092 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

3. April 6, 20093 Based on rewriting of query Create authorization view R A In user query, replace R by R A 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 lineitem where shipmode=‘express’ σ L σ authL σ O σ L

4. 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, 20094

5. 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, 20095

6. Query Rewriting Model April 6, 20096 An authorized View CREATE 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θi θ1θ1 θ2θ2

7. April 6, 20097 Redundancy Removal Most queries access only authorized data

8. April 6, 20098 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

9. April 6, 20099 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

10. 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, 200910 θiθi θiθi θiθi

11. 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, 200911 θ1θ1 θ2θ2 θ1θ1

12. April 6, 200912 TPC-H Benchmark Queries, with authorization checks Comparing normalized execution times Performance benefits of RR TPCH QueryExecution Time Without RR Execution Time With RR Query 3100.0048.28 Query 656.0338.79 Query 1094.8355.45 Query 1277.5743.97 Query 1449.1438.79

13. April 6, 200913 Information Leakage So you thought only the query result matters?

14. April 6, 200914 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) employeesA1 σ myudf(E.salary) employees A1

15. April 6, 200915 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

16. April 6, 200916 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) employeesA1

17. April 6, 200917 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

18. 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, 200918

19. April 6, 200919 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

20. April 6, 200920 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

21. April 6, 200921 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 G5 G7 G1 G4 G2 G6 G3 σ employees medical-records Q1

22. April 6, 200922 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

23. Both RR and Optimal Safe Plan are necessary: Motivation No RRWith RR UDF on top10047.83 Safe Optimal53.2523.25 April 6, 200923 Comparing normalized execution times.

24. April 6, 200924 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

25. 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, 200925

26. 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, 200926

27. 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, 200927

28. 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, 200928

29. April 6, 200929 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 Authorization View replacement σ σ

30. April 6, 200930 Both RR and Optimal Safe Plan are necessary No RRWith RR UDF On Top Safe Optimal UDF On Top No RR Apply RR Apply Both 47.83 23.25 100.00 53.25

31. April 6, 200931 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

32. Thank You!! Questions???? April 6, 200932