fine grained authorization through predicated grants surajit chaudhuri, tanmoy dutta, s. sudarshan...

Fine Grained Authorization Through Predicated GrantsSurajit Chaudhuri, Tanmoy Dutta, S. Sudarshan

(ICDE 2007)

Presented By:Presented By:

Ahmad AbusalahAhmad Abusalah

[email protected]@cs.purdue.edu

BackgroundBackground

SQL standards:SQL standards:SQL 1999SQL 1999SQL 2003SQL 2003SQL 2008SQL 2008

Access Control. Access Control. Authorization.Authorization.Security Model.Security Model.

SQL Security SQL Security ModelModel

SQL:1999 new security facility is found in its role capability. Privileges can be granted to roles just as they can be to individual authorization identifiers.

SQL:2003 , SQL:2008 modifications of non-core features and not related to security.

Can be used Interchangeably

Access to Database:

User Login with password

Access to Objects

Which Object?

What Action?

Do we have what we need?Do we have what we need?What We Have:What We Have:

Coarse-grained authorization modelCoarse-grained authorization model

Granularity = Table

Grants access to all rows of a table or none at all

Finer-grained authorization:Views with built-in built-in functions (userid())functions (userid())

Queries to be phrased against the views rather than on the originalTable Requires rewriting significant parts of anApplication

different queries would have to bewritten for users with different degrees of authorizations

Granularity = Table



Granularity = Table


Queries to be phrased against the views rather than on the originalTable Requires rewriting significant parts of anApplication

different queries would have to bewritten for users with different degrees of authorizations


Granularity = Table


Do we have what we need?Do we have what we need?

SQL Fine-grained authorization modelSQL Fine-grained authorization model

Granularity = Rows and even to specific Columns values Cells

What We Need:What We Need:

Fine-grained authorization implementation should move to the database instead of application layer

Authorization checks are distributed over a large body of code

Security, trust, and simplicity issues

Fine-grained authorization implementation should move to the database instead of application layer

Authorization checks are distributed over a large body of code

Security, trust, and simplicity issues

How to Meet?How to Meet?What We Propose:What We Propose:

Extend the SQL authorization model to support fine-grained authorization

Such extension to SQL must have the following characteristics:

•Clear and simple semantics.

•Compatibility with existing SQL security model, with minimal changes.

•Ease of specification and administration of authorization.

•The ability to deal with (large numbers of) application users, not just a set of fixed database users/roles.

•Low impact on existing application code.

How to Meet?How to Meet?How to Extend:How to Extend:

Using Predicates: Applied on read and update of rows. Applied on execution of functions and procedures

Column-level authorization, including variants that allow: nullification of values based on predicates cell-level security Authorization on aggregates, while restricting authorization on the underlying data.

Support administration of systems with large numbers of application users and database objects including:

Query-defined user groups. Authorization groups











GoalGoal

“The main goal of this paper is to present to the community a detailed initial proposal for extending SQL to support fine grained authorization, addressing important issues that arise in this context. Our hope is that this will eventually lead to extensions to the SQL standard, through refinement of the proposal.”

OutlineOutlineOutlineOutlineProposed Extensions:Proposed Extensions:

Predicates in Grants

Authorization on Procedures/Functions

Query-Defined User Groups

Authorization on Columns

Aggregate Authorizations

Authorization Administration Features

Stacked Grants

Open Areas to explore.Open Areas to explore.

OutlineOutlineProposed Extensions:Proposed Extensions:







Stacked Grants


Predicates in GrantsPredicates in GrantsUsage:Usage:

grant <Perm> on <obj>

where (<Pred>) to <subj> [as <auth-name>]

Goal:Goal:A predicated grant statement authorizes access only to

rows that satisfy the grant predicate

Example:Example:

Each person is granted access to their own employee record.

grant select on employeewhere (empid = userId()) to public

grant select on employee E where (E.deptid in (select deptid from manages where mgrid = userId()))to public

Each department head is granted access to the records of his employees

Predicates in GrantsPredicates in GrantsUsage:Usage:

grant <Perm> on <obj>

where (<Pred>) to <subj> [as <auth-name>]

Goal:Goal:A predicated grant statement authorizes access only to

rows that satisfy the grant predicate

Example:Example:

SemanticsSemanticsSemantics for Queries:Semantics for Queries:

grant select on R where P to U

The semantics of the grant is that all uses of R in any queries issued by the database user U are replaced by the expression:

select * from R where P

If a user has multiple authorizations

with predicates P1..Pn, then

the disjunction (P1v …v Pn)

is used in place of P in the above expression.

SemanticsSemanticsSemantics for Updates:Semantics for Updates:

grants all (select, insert, delete and update)authorization to all employee recordswith dept-id = Sales, to SalesDept

grant all on employee where deptid =’Sales’ to SalesDept

• For updates, the old and new value of any updated tuple must satisfy the update authorization predicates.

• Inserts, deletes and updates on tuples that violate the predicate are rejected

update employeeset phone = ‘555-1212’, deptid = ‘Legal’where empid = ‘1234’

If the employee 1234 was in the Sales department, the user would have authorization to update the phone number, but the update to deptid would fail since the updated tuple fails the authorization predicate (deptid = ‘Sales’).








Stacked Grants


Authorization on Procedures/FunctionsCurrent SQL standard supports:Current SQL standard supports:

grant execute on proc() to U

Proposed Extension:Proposed Extension:Use predicated grants:

grant execute on proc()

where <Pred>

to <Sub>

Example:

grant execute on getsalary(userid)

where (userid = userId())

to employeeGrp








Stacked Grants


Query-Defined User GroupsScenario:Scenario:

Assign a set of permissions to managers only and not any other employee

Current SQL standard supports “Roles”Current SQL standard supports “Roles” - Which are groups of permissions on objects assigned to

individual users.

Maintenance overhead each time individuals’ list is changed.

1st Proposed Extension: (Predicated Grants)1st Proposed Extension: (Predicated Grants)

grant select on employee E where (E.deptid in (select deptid from manages where mgrid = userId()))to public

Most of users are not managers

Checking the predicate each time we access the employee table is unnecessary overhead

Query-Defined User Groups2nd Proposed Extension: (Query defined user groups)2nd Proposed Extension: (Query defined user groups)

create group managerGrp as(select mgrid from manager)

How to create it?

Group has an associated query that returns the set of application user-ids that belong to the group

What is it?

grant select on employeewhere (deptid in

(select deptid from managerswhere mgrid = userId()))

to managerGrp

How to assign permissions?

Less overhead








Stacked Grants


Authorization on ColumnsGoal:Goal:

Permissions to be assigned to specific columns only

Current SQL standard:Current SQL standard:- This feature is supported- Grant select (col_name) on table_name to user

Maintenance overhead each time individuals’ list is changed.

Simple and efficient

Proposed Extension: (Predicated Grants)Proposed Extension: (Predicated Grants)

grant select on employee(name)where (dept =’sales’) to public

Issues:Issues:- A user may have multiple grants on different columns of a relation, with different predicates.- A query may access columns covered by different authorizations.

Authorization on ColumnsIssues:Issues:- A user may have multiple grants on different columns of a relation, with different predicates.- A query may access multiple columns covered by different authorizations.

Proposed Model 1.Proposed Model 1.Use only authorizations that cover all accessed.

Example:Example:User has Pa on column A,Pb on column B, Pc on Columns A,b.If Q accesses A & B then allow access to rows that satisfy Pc.

Proposed Model 2.Proposed Model 2.Cover different authorizations, but only return rows that satisfy all the predicates associated with the authorizations

Example:Example:User has Pa on column A.Pb on column B. If Q accesses A & B then allow access to rows that satisfy Pa and Pb only.

Proposed Model 3.Proposed Model 3.Cover different authorizations, and return rowswhere at least one column satisfies the authorizationpredicate on the column.However, nullify cells for which none of the applicable authorization predicates evaluate to true.

Authorization on ColumnsIssues:Issues:- A user may have multiple grants on different columns of a relation, with different predicates.- A query may access multiple columns covered by different authorizations.

Cell-Level Authorization with Nullification

Scenario:Scenario:Allow access to the address attribute of employees who have ‘opted-in’ to allow their addresses to be made public, butReturn a null value for the address attribute of all other employees

Proposed Extension: (Predicated Grants & “else nullify”)Proposed Extension: (Predicated Grants & “else nullify”)

-The else nullify clause can only be specified on columns whose types permit null values.

- It cannot be used on primary key columns, for example.

- If a grant with nullify is specified on a column, queries can access that column, but the value returned for a row will be null unless the predicate is true for at least one of the grants.

grant select on employee(addr) where (P1) else nullify to public

grant select on employee(phone) where (P2) else nullify to public

grant select on employee(empid) where (P0) to public

Cell-Level Authorization with Nullification

Example:Example:

- Thus, if predicates P1 (resp. P2) in the abovegrants evaluate to false for a particular row for a particular user, that user will see null values for the address (resp. phone) attribute of the row.

- On the other hand, if a query accesses an attribute on which else nullify is not specified, such as empid in the above example, the entire tuple will become inaccessible (including attributes for which else nullify has been specified).

grant select on employee(addr) where (P1) else nullify to public

grant select on employee(phone) where (P2) else nullify to public

grant select on employee(empid) where (P0) to public

Example:Example:








Stacked Grants


Aggregate AuthorizationsGoal:Goal:

Authorization can be granted on aggregated values, instead of individual values

Example:Example:To allow a salesperson to see the aggregate of sales in theirregion.

grant select on sales(region, category,anyagg(units), anyagg(price)) where (region = getUserRegion()) to salesGrp

select region, sum(units) from salesgroup by region

select sum(units)from sales

Same ResultSame ResultSame Result

select region, sum(units) from salesgroup by region Same Result

select sum(units)from sales

select region, sum(units) from salesgroup by region Same Result








Stacked Grants


Authorization Administration FeaturesHierarchies of groups:Hierarchies of groups:Scenario: To have group B inherit all members of group A, the group A can be used in the query defining group B

create group A as (…)

create group B as A union (…)

Authorization GroupsAuthorization Groups::Goal: Define a set of authorizations on a group of related objects..

create authorization select_purchaseorder

with root order O as ( select on order O,select on lineitem L where (L.order_id=O.order_id)),select on part P where (P.part_id=L.part_id),select on partsupp PS where (PS.part_id = P.part_id),select on supplier S where (S.supplier_id = PS.supplier_id))

grant select_purchaseorderwhere(purchaser_id = userId())to employeeGrp








Stacked Grants


Stacked Grants

Properties for a valid Stacked Grants:Properties for a valid Stacked Grants:

1. A grantor A can only pass on authorizations that hadbeen granted with grant option to the grantor.

2. The grant predicate cannot reveal information to thegrantee B that was not visible to the grantor A, or wasnot granted with grant option to A.

3. Cycles in Stacked Grants is disallowed through the use of authorization graph.

Stacked GrantsWhat is it?What is it?The issue of further granting of predicated grants, is referred to

as stacked grants

grant select on R where P1 to A with grant option;

Then, user A executes

grant select on R where P2 to B;

Stacked GrantsWhat Data B can access?What Data B can access?

grant select on R where P1 to A with grant option;

Then, user A executes

grant select on R where P2 to B;

Answer1: (P1 Answer1: (P1 ΛΛ P2)? P2)?

Incorrect!Incorrect!since P1 is only authorized to see data satisfying P1 with values from his/her user context. Suppose P1 is of the form “empid=userId()”, the userId() value for A is 1234, and that of B is 2345Then A is authorized only to access (and grant access to) tuples with empid='1234’.

Answer2: (P1’ Answer2: (P1’ ΛΛ P2’)? P2’)?

Correct!Correct!P1’ is the result of replacing instances of userId() in P1 bythe user-id of A. P2’is the result of replacing relations in P2 by the views availableto user A.








Stacked Grants

Open Areas to Explore.Open Areas to Explore.

Open Areas to ExploreOpen Areas to Explore

Query Optimization:Query Optimization:Query modification to implement fine-grained authorization must

be done each time a query is submitted, which can have a non- trivial cost.

To reduce this cost, we can cache the rewritten query Q’ derived from Q, as well as the recompiled plan.

Managing authorizationsManaging authorizations.

Extensions to efficiently handle hierarchies handle hierarchies of various types, such as organizational hierarchies, user hierarchies and user-interface hierarchies are required.

Integration of database and application level authorizationdatabase and application level authorization

Thanks!Thanks!

fine grained authorization through predicated grants surajit chaudhuri, tanmoy dutta, s. sudarshan...

Documents

authorization groupshow

sql authorization model

fine grained authorization

allfinergrained authorization

update of rows

execution of functions

sql standard

tablegrants access