Download an Overview of Finegrained Authorization

Fine-Grained Authorization
in Databases
S. Sudarshan
IIT Bombay/Microsoft Research
Parts of this talk joint work with
Rizvi, Mendelzon and Roy
Access Control & Databases
USERS
DBA
Oct 5, 2004
CASCON 2004
2
Roadmap


Motivation
Fine-grained access control models






Unconditional and Conditional Validity



View Replacement Model
Oracle VPD
Non-Truman Model
Cell-level Authorization and Nullification
Multi-Level Security
Inferring validity
Etc.
Conclusions
Oct 5, 2004
CASCON 2004
3
Fine Grained Access Control

Fine-grained access control examples:





Students can see their own grades
Students can see grades of all students in courses they
registered for
 Variant: but not the associated student-ids
Public can see average grades for all courses
Faculty can see/update/insert/delete grades of courses
they taught
SQL does not support such authorization

Oct 5, 2004
SQL authorization at the level of table/column
 not row level
CASCON 2004
4
Fine-Grained Authorization


Usual solution: fine-grained authorization
handled by application programs
Application-layer access control limitations






Complex, redundant code
Malicious/careless programmers
SQL injection problems
Application code runs in “super-user” mode
always
Repeated security logic
Solution: access control inside database
Oct 5, 2004
CASCON 2004
5
Access Control Using Views



Common solution: Views
create view ShawnGrades as
select * from Grades where student_id = 'Shawn'
q
select grade from ShawnGrades
where course = 'CS262B'
Per-user views – difficult to administer
Solution: parametrized views


v
create view MyGrades as
select * from Grades where student_id = $userid
Authorization-conscious querying

Oct 5, 2004
Instead of grades, must use MyGrades for students,
another view for faculty, etc,
CASCON 2004
6
Access Control Requirements

Authorization-transparent querying


Queries written on base relations
System can





Replace relations by authorized views, or
Accept and run as is if safe, else reject query
Avoid erroneous/misleading answers
No erroneous query rejections
Minimal time overhead in query processing
Oct 5, 2004
CASCON 2004
7
Authorization-Transparent Querying


View-level data independence
Analogous to physical/logical data
independence



Changes to underlying authorization should not
directly affect queries
Querying base relations rather than views
Easy to build applications


Oct 5, 2004
Views can be user-specific, for multi-user apps
Generated queries better not be user-specific
CASCON 2004
8
The View Replacement Approach



AKA: Filter model
Transparent query modification
“Grades of all students”
q
select * from Grades
qm
select * from Grades
where studeint_id = ‘Shawn'
“Grades of current user (Shawn)”
Used in Oracle’s Virtual Private Database
Oct 5, 2004
CASCON 2004
9
Oracle VPD

Predicates transparently added to query/update where
clause


User-defined functions (specified by application)
generate the predicates



for each relation used in query/update
Functions encode security logic, can be in C/Java
Secure application context stores session parameters,
which can be accessed by function
Application context


Oct 5, 2004
Database user information is insufficient, need to know
application user
Oracle provides mechanism for application to inform DB
about end user
 Handles DB connection pooling
CASCON 2004
10
Oracle VPD (Cont.)

Example applications
Application service providers (hosted applications)
 E.g predicate: companyid = AppContext.comp_id()
Web applications
 E.g. predicate userid = AppContext.userid()



Extensions in 10g
E.g. Relevant column enforcement and masking


Flaw in the model that allows information leakage
found recently
and apparently fixed

Flaw: User defined functions with side effects can leak
information if executed before VPD inserted predicate
Oct 5, 2004
CASCON 2004
11
The Truman Show (1998)
“He's a prisoner. Look at him, look at what you've done to him!”
Oct 5, 2004
CASCON 2004
12
Drawbacks of View Replacement

May provide misleading information



Query executes in an artificial world
Inconsistencies between the answer and user’s
external information
Even if query is actually authorized!
q
select avg(grade) from Grades
“Average grade across all courses
and across all students”
qm
select avg(grade) from Grades
where student_id = ‘Shawn’
“Average grade across all courses
for the current user”
Oct 5, 2004
CASCON 2004
13
The Authorization Inferencing
(Non-Truman) Model

User queries written on base relations

Authorization-transparent querying


But can access views if so desired
Idea: If query can be answered using information in
authorized views


Then accept query and execute as is
Else reject query
v
q
Oct 5, 2004
create authorization view MyGrades as
select * from Grades
where sid = $user-id
select * from Grades
where sid = '16856612'
CASCON 2004
14
Authorization Inferencing: History

Query rewriting using views




Partial results for unauthorized queries
Description of incompleteness
Query q authorized if any equivalent query q'
(possibly using views) is authorized



(Motro [ICDE89, JIIS96])
(Rosenthal & Sciore [DBSec99, DBSec01, DMDW00])
Applications in data warehousing
Extended to “conditional equivalence”


Oct 5, 2004
(Rizvi, Mendelzon, Sudarshan and Roy, [SIGMOD’04])
More on this later
CASCON 2004
15
Authorization Inference

Benefits:



Correctness of answers guaranteed
Query executed as written without modification
Drawback:

Inferencing undecidable in general



False rejection possible
More on inferencing later…
How to handle “show me everything I’m
authorized to see” (within query result)?

Oct 5, 2004
Integration with view replacement model?
CASCON 2004
16
Cell Level Authorization

E.g: P3P opt-in/opt-out model




Patient names are released to pharmacy
 patient can opt-in to have email disclosed to pharmacies
Pharmacy issues “select name, email from patient”
Show information in cell if authorized, else return
null
Limited disclosure models and implementation
approaches

LeFevre et al [VLDB04]
Storage alternatives

Query alternatives: outerjoin vs. subquery in select clause

Oct 5, 2004
CASCON 2004
17
Multi-Level Security

Security level with each tuple and security clearance
level for each user





Oracle Label Security




E.g. top-secret, secret, confidential, pubilc
Read allowed only on data with lower security level than
users clearance
“Write down” may be prohibited
Not a fully general solution
 E.g. cannot handle “students can see only their own
grades”
Allows sensitivity labels plus “compartment” plus “group”
Now allows SQL predicates to be added to label security
IBM DB2 for zOS
Work at IBM Toronto (Rjaibi and Bird, VLDB04)

Oct 5, 2004
Adds labels to MLS
CASCON 2004
18
Extending Query Rewriting
Techniques for Fine-Grained
Access Control
Shariq Rizvi
Alberto Mendelzon
UC Berkeley
University of Toronto
S. Sudarshan
Prasan Roy
IIT Bombay
IBM IRL
Our Contributions

Non-Truman model


Conditional validity




Formalization of access control by query rewriting
using views
A new dimension to query rewriting using views
Required to capture a special class of valid
queries
Inference rules to deduce query validity
An implementation framework for this model
Oct 5, 2004
CASCON 2004
20
The Non-Truman Model

Test: Is the query q “valid” under the given
authorization?



If yes, execute it unmodified
Else, reject it
Hence


Oct 5, 2004
Authorization-transparent querying
No query modification
CASCON 2004
21
Unconditional Validity
DEFINITION (Unconditionally Valid Query)
“A query q is said to be unconditionally valid if:
there is a query q' that is written using only the
instantiated authorization views, and is
equivalent to q.
That is, q and q' produce the same result on all
database instances”
(Equivalence refers to multiset equivalence)
Oct 5, 2004
CASCON 2004
22
Basic Inference Rules for
Unconditional Validity

Inference rule U1

If the query is an authorization view, it is valid
Auth View

Inference rule U2

Oct 5, 2004
If the query combines only unconditionally valid
subqueries, it is unconditionally valid
CASCON 2004
23
Implementing inference rule U2:
Query Rewriting Using Views

Extensive work by database community


Query optimization, view maintenance, data
integration systems, …
Testing complete rewriting with conjunctive
query and conjunctive views is NP-hard (Halevy
[VLDBJ01])

Queries with arithmetic comparisons (Chaudhuri et
al. [ICDE95])


Oct 5, 2004
Multiset semantics (Chaudhuri et al. [PODS94])
Queries/views with aggregation/grouping
(Gupta
et al. [VLDB95], Levy et al [PODS95], Chaudhuri and Shim [EDBT96],
Srivastava et al. [VLDB96], Cohen et al. [PODS99], Bello et al [VLDB98],
Zaharioudakis et al. [SIGMOD00], Larson et al [SIGMOD01], etc)
CASCON 2004
24
Unconditional Validity Is Too
Strong!
v
q
create authorization view MyDocuments as
select Document.*
from User, Document
where User.uid = $user-id
and Document.level <= User.level
select * from Document
where doc-id = '5'
“A user can see all documents
rated lower than or equal to her
level”
“Return document 5”
What should happen?


Query is valid if
 Document 5 is present, and is rated ≤ the user’s level
Query is invalid if
 Document 5 is present, and is rated > the user’s level
 Document 5 is absent
Oct 5, 2004
CASCON 2004
25
Unconditional Validity Is Too
Strong!
What should happen?
 Query is valid if


False Negative!
Document 5 is present, and is rated ≤ the user’s level
Query is invalid if


Document 5 is present, and is rated > the user’s level
Document 5 is absent
What will happen with just unconditional validity?
 Query is declared invalid

Unconditional validity decides without looking at the database
Need a notion of validity that looks into the database and is
sensitive to the above cases!
Oct 5, 2004
CASCON 2004
26
Beyond Unconditional Validity

Unconditional validity gives false negatives




q and q' - equivalence over all database
instances
But user has some information on the current
database instance (from the authorization views!)
So, equivalence over a more restricted set of
instances should do fine!
Naïve take: Test equivalence on the current
database state

Oct 5, 2004
Too weak: leaks information
CASCON 2004
27
A Special Set of Database
Instances

Need equivalence on a set of database instances that
captures exactly what the user knows

PA-Equivalent database states: database instances
(states) that give the same result for all authorization
views
P = database states PA-equivalent to the current
database state Intuition: The user can not distinguish
any two instances in P from each other but can
distinguish an instance in P from an instance outside P

Current databas
state
U
P
Oct 5, 2004
CASCON 2004
28
Conditional Validity
DEFINITION (Conditionally Valid Query)
“A query q is said to be conditionally valid if:
there is a query q' that is written using only the
instantiated authorization views, and is
equivalent to q over all database instances that
are PA-equivalent to the current database
instance”
Oct 5, 2004
CASCON 2004
29
Inferring Conditional Validity

Basic idea: generate “test queries” to lookup
the database

Back to example
select distinct 1 from Document
where doc-id = '5' and level <= 7



Result should be non-empty
This query itself should be conditionally valid
Set of inference rules incomplete*

But handles a large class of queries
*Extensions and ongoing work (with Navneet Loiwal, IIT Bombay)
Oct 5, 2004
CASCON 2004
30
Conclusions (for Authorization Checking)




Inference rules implemented (partially) into a Volcano-style query
optimizer
 Piggy-back on the rewriting capability of the query optimizer
Sufficient conditions for conditional validity are expensive
 Requires “test queries” to be executed
 Ideas on caching/reusing inferences need to be tested
Exact (but extremely expensive) test for conditional equivalence
for conjunctive queries (Zhang and Mendelzon, ICDT 05)
Unconditional and conditional validity testing are undecidable in
general
 Can users live with notion that a query may be unfairly rejected
even if actually authorized?
 How rare would this be in reality?
Oct 5, 2004
CASCON 2004
31
Overall Conclusions


Lots of interest in fine-grained access control
View replacement vs. authorization checking model



Each has its benefits and drawbacks\
Multi-level security of limited value without integration
with other forms of fine-grain authorization
Need to worry about application developer


Oct 5, 2004
User interface needs to check for authorization, even if
enforced at database
Are we easing developers task or doubling their work?
CASCON 2004
32
Extra Slides
Take-away
You don’t want to do this!
Too strong
dcurrent
Just right
U
P
Oct 5, 2004
CASCON 2004
34
Non-Truman Model: Authorization
Specification


Normal relational views
Parameterized views


Instantiated on access
Administered to users using SQL grant/revoke
Oct 5, 2004
v1
create authorization view AllGrades as
select * from Grades
v2
create authorization view MyGrades as
select * from Grades
where sid = $user-id
CASCON 2004
35
Non-Truman Model: User
Queries

User queries written on base relations

Authorization-transparent querying
v
q
Oct 5, 2004
create authorization view MyGrades as
select * from Grades
where sid = $user-id
select * from Grades
where sid = '16856612'
CASCON 2004
36
Non-Truman Model: The Test

DBMS tests if the query is valid



Oct 5, 2004
Intuition: A query is valid if it can be answered using the
information contained in the authorization views available
to the user
We develop the formalization next
Example (assuming the user is 16856612):
v
create authorization view MyGrades as
select * from Grades
where sid = $user-id
q
select * from Grades
where sid = '16856612'
CASCON 2004
37
Example
“A user can see the
course-id of all courses
she has registered for”
create authorization view MyCourses as
select course-id from Registered
where sid = $user-id
v1
v2
“A user can see all her grades”
q
create authorization view MyGrades as
select MyCourses.course-id, Grades.grade
from MyCourses, Grades
where MyCourses.course-id = Grades.course-id
select Registered.course-id, Grades.grade
from Registered, Grades
where Courses.course-id =Grades.course-id
and Registered.sid = '16856612'
q'
Oct 5, 2004
“Return all my grades”
select course-id, grade from MyGrades
CASCON 2004
38
Inference Rules using Integrity
Constraints
If:
q1 select Ac , Ar from Rc , Rr
where Pc ^ Pr ^ Pj
And:
Integrity constraint
qualifying tuples in Rc there is a qualifying matching
tuple (w.r.t Pj) in Rr (e.g., foreign key constraints)
A
Infer:
q2 select distinct Ac from Rc where Pc
Oct 5, 2004
CASCON 2004
39
Example
q1 = v
create authorization view RegStudents as
select s.name, r.course-id
from Students s, Registered r
where s.student-id=r.student-id
“Names of students and course-id’s they have registered for”
Integrity constraint
Each student must register for at least one course
q2 = q select distinct name from Students
Given the integrity constraint, the user can see all distinct
names from the authorization view anyway!
Oct 5, 2004
CASCON 2004
40
Naïve Take Leaks Information
q
select * from Document where doc-id = '5'
Naïve Test
Is there a query q' written on view MyDocuments equivalent to q over the current
database instance?

Case 1: document 5 present AND its level ≤ user’s level


Equivalent query is select * from MyDocuments where doc-id = '5'
Case 2: document 5 present AND its level > user’s level


ACCEPT
REJECT
No equivalent query
ACCEPT
Case 3: document 5 not present

Equivalent query is empty query
Information Leak: Cases 2 and 3 were indistinguishable to the
user with just the MyDocuments view, but now they are
distinguishable!
Oct 5, 2004
CASCON 2004
41