Transcript CS 579 Database Systems

Advanced
Database Topics
Copyright © Ellis Cohen 2002-2005
Access Control Mechanisms
These slides are licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 2.5 License.
For more information on how you may use them,
please see http://www.openlineconsult.com/db
1
Overview of Lecture
Security Predicates & Policies
Role-Based Access Control (RBAC)
Solving Security Problems with Roles, Dynamic
Views, and Security Predicates
Hierarchical RBAC
Group-Based Access Control (GBAC)
Groups with Selective Denial (GSD)
Access Control Lists (ACLs)
Security Domains &
Operation-Based Access Control
Dynamic Security
User-Based Access Control
in Multi-Tier Applications
Application-Based Access Control
Mandatory Access Control Mechanisms (MAC)
Statistical Database Access
© Ellis Cohen 2002 - 2005
2
Security Predicates
& Policies
© Ellis Cohen 2002 - 2005
3
Security Predicate Mechanism
Security predicate mechanisms
provide fine-grained access control
without the need to explicitly define views.
Basics of the Mechanism:
• The owner of a table associates a security
predicate string with it.
• Whenever another user queries the table, the
security predicate string is automatically used as
(or ANDed with) the WHERE clause of the query
to effectively define a new view
• The user operation is then performed against this
automatically defined view
Oracle provides such a mechanism,
but with somewhat different details
© Ellis Cohen 2002 - 2005
4
Security Predicate Example
Suppose SCOTT wants to allow a user to only
access their own row of the Emps table
SCOTT> ASSOCIATE
'empno = AuthPkg.GetUser()'
WITH Emps;
SCOTT> GRANT SELECT ON Emps
TO PUBLIC
TOMMY> SELECT * FROM SCOTT.Emps
 effectively rewritten as
TOMMY> SELECT * FROM SCOTT.Emps
WHERE empno = SCOTT.AuthPkg.GetUser();
© Ellis Cohen 2002 - 2005
5
Security Policies
Security Policies generalize Security Predicates
The owner of a table/view can
associate multiple security policies
with a table/view. Each one consists
of
– A security predicate string (or a function
which returns such a string)
– Optionally, one or more of
SELECT, INSERT, UPDATE, DELETE, with
optional column specifications, which
determines when/how each security
predicate is applied.
– This effectively "grants" the
corresponding privileges to PUBLIC
© Ellis Cohen 2002 - 2005
6
Security Policy Example
SCOTT> ASSOCIATE
'mgr = AuthPkg.GetUser()'
WITH Emps
FOR UPDATE(sal), SELECT(empno,sal);
– only an employee's manager can see/update
their salary. Automatically grants UPDATE(sal)
and SELECT(empno,sal) to PUBLIC.
TOMMY> SELECT empno, sal FROM SCOTT.Emps
 effectively rewritten as
TOMMY> SELECT empno, sal FROM SCOTT.Emps
WHERE mgr = SCOTT.AuthPkg.GetUser()
How would you specify that an
employee's number, name or job can be seen by any employee,
but their job can only be changed by a dept manager?
© Ellis Cohen 2002 - 2005
7
Security Policy Solution
SCOTT> ASSOCIATE
'AuthPkg.GetUser() IS NOT NULL'
WITH Emps FOR SELECT(empno,ename,job);
– only an employee can see an employee, name,
number or job
SCOTT> ASSOCIATE
'(SELECT job FROM Emps WHERE
empno = AuthPkg.GetUser()) = ''DEPTMGR'''
WITH Emps FOR UPDATE(job);
– only a dept mgr can update a job
TOMMY> UPDATE SCOTT.Emps
SET job = 'CLERK WHERE ename = 'JONES'
 effectively rewritten as
Suppose this
updated sal as well
as job?
TOMMY> UPDATE SCOTT.Emps
SET job = 'CLERK'
WHERE ename = 'JONES'
AND SCOTT.AuthPkg.GetUser() IS NOT NULL
AND (SELECT job FROM SCOTT.Emps WHERE
empno = SCOTT.AuthPkg.GetUser()) = 'DEPTMGR'
© Ellis Cohen 2002 - 2005
8
Delegation Issues
Suppose the owner of a table (or
view) wants to delegate to another
user the ability to add, remove or
alter security policies for that object?
How would you design that?
Would an owner ever want to
delegate to another user the ability
to only modify or further constrain a
specific security policy?
© Ellis Cohen 2002 - 2005
9
Role-Based
Access Control
(RBAC)
© Ellis Cohen 2002 - 2005
10
Groups of Privileges & Users
Roles provide a mechanism which simplify
granting the same set of privileges
to a group of users
SCOTT> GRANT SELECT on Emps TO HARRY, ADAMS
SCOTT> GRANT SELECT on Depts TO HARRY, ADAMS
HARRY
select on Emps
ADAMS
select on Depts
Consider the group of users
All play the same role with respect to a DB
application and need the same privileges
Consider the group of privileges
We'd like to bundle them up together to be
given as a group to different users
© Ellis Cohen 2002 - 2005
11
Basic RBAC
Basic idea
– Create a role
– Grant privileges to a role
(but not with the GRANT OPTION)
– Grant the role to the users
– This has the effect of granting all the privileges
in the role to the user
Privileges
Role
HARRY
select on Emps
select on Depts
SCOTT>
SCOTT>
SCOTT>
SCOTT>
Users
InfoRole
ADAMS
CREATE ROLE InfoRole
GRANT SELECT on Emps TO InfoRole
GRANT SELECT on Depts TO InfoRole
GRANT InfoRole TO HARRY, ADAMS
© Ellis Cohen 2002 - 2005
12
Roles as Groups of Privileges
You can think of a role as
representing a group of privileges
which are then granted to the
appropriate users
Privileges
Role
HARRY
select on Emps
select on Depts
Users
InfoRole
ADAMS
Somewhat similar to "capability lists"
© Ellis Cohen 2002 - 2005
13
Revoking Privileges from Roles
A user U can revoke a privilege
from a role R only if
• U has GRANT OPTION for that
privilege
• U granted the privilege to R
(just like revoking a privilege
from a user)
© Ellis Cohen 2002 - 2005
14
Roles as Groups of Users
You can also think of a role as
representing a group of users to
whom privileges are granted
Privileges
Role
HARRY
select on Emps
select on Depts
Users
InfoRole
ADAMS
Similar to OS user groups
© Ellis Cohen 2002 - 2005
15
Granting Roles
Who can grant a role to a user
(i.e. who can decide which users
make up the user group)
– Creator of the role
– A user who was granted the role
with the ADMIN option
Admin Option
SCOTT> CREATE ROLE Developer
SCOTT> GRANT Developer TO FLICKA
WITH ADMIN OPTION
FLICKA> GRANT Developer TO MERCURIO
© Ellis Cohen 2002 - 2005
16
Roles Use
Centralized Administration
Who can revoke a role from a user?
• The creator of the role
• Any administrator of the role – i.e.
any user who has been granted the
role with the ADMIN OPTION
Revocation only cascades if CASCADE
is specified as part of the REVOKE
command (not supported in Oracle)
© Ellis Cohen 2002 - 2005
17
Simulating Centralized
Administration of Privileges
SCOTT> CREATE ROLE SelectEmps
SCOTT> GRANT SELECT On Emps
TO SelectEmps
SCOTT> GRANT SelectEmps
TO FLICKA, SMITH, JONES
WITH ADMIN OPTION
FLICKA> GRANT SelectEmps TO ADAMS
– FLICKA effectively grants
– SELECT ON Emps to ADAMS
SMITH> REVOKE SelectEmps FROM ADAMS
– SMITH effectively revokes
– SELECT ON Emps from ADAMS
© Ellis Cohen 2002 - 2005
18
Simulating Sub-Centralized
Administration of Privileges
SCOTT> CREATE ROLE SmithSelectEmps
SCOTT> GRANT SELECT On Emps TO SmithSelectEmps
SCOTT> GRANT SmithSelectEmps TO SMITH
WITH ADMIN OPTION
SCOTT> CREATE ROLE FlickaSelectEmps
SCOTT> GRANT SELECT On Emps TO FlickaSelectEmps
SCOTT> GRANT FlickaSelectEmps TO FLICKA
WITH ADMIN OPTION
FLICKA> GRANT FlickaSelectEmps TO DILIP
WITH ADMIN OPTION
FLICKA> GRANT FlickaSelectEmps TO CHU
WITH ADMIN OPTION
FLICKA can (via FlickaSelectEmps) effectively revoke
SELECT ON Emps to every user to whom it has been granted
(through FlickaSelectEmps).
But FLICKA cannot (effectively) revoke SELECT ON Emps from users
to whom it was granted via SmithSelectEmps; SMITH can though.
© Ellis Cohen 2002 - 2005
19
Enabling Roles
Granting a role to a user does not
automatically allow the user to exercise
its privileges
Users must enable roles
Ensures that a user only has privileges relevant
to the role they are exercising
Enabling roles (e.g. by harry)
SCOTT> grant InfoRole to HARRY
HARRY> set role InfoRole
HARRY> select * from Emps
(In Oracle) Default enabled roles can be set
by the DBA for a user via ALTER USERS
PUBLIC is effectively a role granted to and
automatically enabled for all users
© Ellis Cohen 2002 - 2005
20
Questions about Roles
Role names in Oracle are global rather than schemaspecific (e.g. FLICKA uses Developer, not
SCOTT.Developer). What are the pros and cons of this
design decision?
If SCOTT grants role A and role B to a user, can SCOTT
ensure that only one of them is enabled at a time? Why
might that be useful?
Can roles be individually disabled? Why?
If a privilege is revoked from a role, does a user who has
enabled the role lose the ability to exercise the privilege
immediately?
If a role is revoked from a user (directly or indirectly), does
a user who has enabled the role lose the ability to
exercise the privileges in the role immediately?
Can a privilege be granted to a role with the grant option
(allowing a user granted that role to then grant the
privilege)?
Suppose A grants a role to B with the admin option, and B
grants the role to user U. When A revokes the role from
B, will U still be able to enable the role?
© Ellis Cohen 2002 - 2005
21
Solving Security
Problems with Roles,
Dynamic Views &
Security Predicates
© Ellis Cohen 2002 - 2005
22
Solving Role-Specific Security Problems
Suppose SCOTT is the administrator (and owner) of
the company's employee information table, Emps
(empno, ename, deptno, addr, mgr, job, sal )
SCOTT wants to allow department managers
(employees whose job is 'DEPTMGR') to be able to
see all employee names and addresses.
How can SCOTT do this
(a) Using Roles
(b) Using Dynamic Views or Security Policies
(Hint: define a view of Emps that provides
names & address, but only if the current user's
job is DEPTMGR. Note: Assume that
AuthPkg.GetUser returns the employee # of
the current user)
© Ellis Cohen 2002 - 2005
23
Role-Based Access Control
SCOTT> CREATE ROLE DeptMgr
SCOTT> GRANT DeptMgr
TO Jones, Blake, Clark
– the three department managers
SCOTT> CREATE VIEW NameAddrView AS
SELECT ename, addr FROM Emps
SCOTT> GRANT SELECT ON NameAddrView
TO DeptMgr
But what happens when the company
gets or loses a dept manager?
SCOTT can explicitly grant/revoke the DeptMgr role
But can it be done automatically?
© Ellis Cohen 2002 - 2005
24
Trigger-Based Role Memebership
SCOTT> CREATE TRIGGER AddMgr
AFTER INSERT, UPDATE OF job ON Emps
FOR EACH ROW
WHEN (new.job = 'DEPTMGR')
GRANT Manager
TO AuthPkg.GetDbId( new.empno )
SCOTT> CREATE TRIGGER DelMgr
AFTER DELETE, UPDATE OF job ON Emps
FOR EACH ROW
WHEN (old.job = 'DEPTMGR')
REVOKE Manager
FROM AuthPkg.GetDbId( old.empno )
(where AuthPkg.GetDbId returns the DB login id of the employee
with the specified employee number)
The actual trigger code is just a bit more complicated
© Ellis Cohen 2002 - 2005
25
Using Dynamic Views
SCOTT> CREATE VIEW NameAddrView AS
SELECT ename, addr FROM Emps
WHERE
(SELECT job FROM Emps
WHERE empno = AuthPkg.GetUser())
= 'DEPTMGR'
SCOTT> GRANT SELECT ON NameAddrView
TO PUBLIC
Both this approach and trigger-based role membership
require that the user roles are actually reflected in the
data stored in the database (e.g. Emps.job)
© Ellis Cohen 2002 - 2005
26
Using Security Predicates
SCOTT> ASSOCIATE
'WHERE
(SELECT job FROM Emps
WHERE empno = AuthPkg.GetUser())
= ''DEPTMGR'''
WITH Emps FOR SELECT(ename, addr)
SCOTT> GRANT SELECT(ename,addr)
ON Emps TO PUBLIC
© Ellis Cohen 2002 - 2005
27
Targeted Security Policies
Instead of granting privileges on different views of a
table to various roles, we can extend security policies
to be user or role-specific
The owner of a table/view can associate
multiple security policies with a table/view.
Each one consists of
– A security predicate string (or a function which
returns such a string)
– Optionally, one or more of
SELECT, INSERT, UPDATE, DELETE, with optional
column specifications, which determines
when/how each security predicate is applied.
– a list of targets: A target is either a role, a user,
or the pseudo-role PUBLIC (the default). This
grants the corresponding privilege to each target.
which determine when/how each security
predicate function is applied.
© Ellis Cohen 2002 - 2005
28
Applying Targeted Security Policies
When a user performs an operation on a table or
view
• the matching security policies are found.
– The user is a target of the security policy, or
– The user has (directly or indirectly) enabled a role
which is a target of the security policy
• The security predicate strings of the matching
policies are used to build a single string
– If there are multiple policies associated with the
same user or role, the strings are concatenated,
separated by AND
– The resulting strings for each distinct user or role
are concatenated together separated by OR
• The resulting string is used as (or ANDed with)
the WHERE clause of a query on the table/view to
automatically define a new view
• The user operation is then performed against this
automatically defined view
© Ellis Cohen 2002 - 2005
29
Targeted Security Policy Example
Suppose any employee can see their own Emps entry, and
a manager can see/update salaries of their employees
SCOTT> ASSOCIATE 'empno = AuthPkg.GetUser()'
WITH Emps FOR SELECT
TARGET PUBLIC
SCOTT> ASSOCIATE 'mgr = AuthPkg.GetUser()'
WITH Emps FOR SELECT(empno,sal), UPDATE(sal)
TARGET Manager
– the Manager role; assume it has been granted to
TOMMY
TOMMY> SELECT sal FROM SCOTT.Emps
 effectively rewritten as
TOMMY> SELECT sal FROM SCOTT.Emps
WHERE empno = SCOTT.AuthPkg.GetUser()
OR mgr = SCOTT.AuthPkg.GetUser()
© Ellis Cohen 2002 - 2005
30
Hierarchical RBAC
(HRBAC)
© Ellis Cohen 2002 - 2005
31
Hierarchical RBAC (HRBAC)
Roles can be granted to other roles
SONI
select
on emp
select
on dept
ADAMS
InfoRole
Developers
JONES
CLARK
Techies
Researchers
BLAKE
© Ellis Cohen 2002 - 2005
32
Roles as
Hierarchical Groups of Privileges
SONI
select
on emp
select
on dept
ADAMS
InfoRole
Developers
JONES
CLARK
Techies
Researchers
BLAKE
© Ellis Cohen 2002 - 2005
33
Roles as
Hierarchical Groups of Users
SONI
select
on emp
select
on dept
ADAMS
InfoRole
Developers
JONES
CLARK
Techies
Researchers
BLAKE
© Ellis Cohen 2002 - 2005
34
Questions about HRBAC
If role A is granted to role B, and role B
is granted to SMITH, does enabling
role B also automatically enable role
A?
Can SMITH just enable role A without
enabling role B?
Can a role be granted to a role with the
admin option? Is this different than
granting privileges to roles with the
grant option?
© Ellis Cohen 2002 - 2005
35
Mechanisms & Design Decisions
After the basic features of a mechanism are
invented
• Some design decisions are made for
– semantic reasons (they actually solve some
problem)
– pragmatic reasons (a different decision would be too
slow or take too much space).
If a design decision made for pragmatic reasons is
really semantically incorrect, it's time to redesign
the mechanism
• Mechanisms can take on a life of their own
– Developers can easily get caught up in thinking
about more and more mechanism tweaks and
features to address deficiencies
– Even when it is time to think about the bigger
picture, which calls for a new approach or
mechanism
© Ellis Cohen 2002 - 2005
36
Group-Based
Access Control
(GBAC)
© Ellis Cohen 2002 - 2005
37
RBAC vs GBAC
In RBAC, Roles can be seen as groups
– Adding a user to a role (i.e. group) is done by
GRANTing the role TO the user.
– This can be done by the creator of the role, or
someone GRANTed the ROLE with the ADMIN
option
GBAC (Group-Based Access Control) uses
explicit groups
– GBAC is a completely different access control
mechanism not available in commercial systems
– Adding a user to a group is done by ADDing the
user TO the group
– This can be done by the creator of the group, or
someone who has been GRANTed the ADD
privilege FOR the GROUP
© Ellis Cohen 2002 - 2005
38
Group-Based Access Control
A group contains a set of names of users and
can be created by any user, e.g.
CREATE GROUP MyGroup
Privileges can be granted (with or without
the GRANT option) to users or to groups, e.g.
GRANT SELECT ON Emps To MyGroup
Uses distributed revocation: A user can only
revoke a privilege (from a group or another
user) that the user previously granted.
A user can exercise a privilege if
– the privilege was granted to the user
– the privilege was granted to a group which
(directly or indirectly) includes that user
© Ellis Cohen 2002 - 2005
39
GBAC vs HGBAC
In GBAC, a group contains a list of users
MyGroup
SCOTT> CREATE GROUP MyGroup
ADAMS
SCOTT> GRANT INSERT ON Emps TO MyGroup
BLAKE
SCOTT> ADD ADAMS TO MyGroup
JONES
SCOTT> GRANT ADD On MyGroup TO FLICKA
FLICKA> ADD BLAKE, JONES TO SCOTT.MyGroup
In HGBAC, a group contains a list of
users and/or other groups
SCOTT> CREATE GROUP BigGroup
SCOTT> GRANT SELECT ON Emps TO BigGroup
SCOTT> ADD CHEN TO BigGroup
SCOTT> ADD MyGroup TO BigGroup
SCOTT> GRANT ADD On BigGroup TO PORTER
PORTER> ADD SONI TO SCOTT.BigGroup
© Ellis Cohen 2002 - 2005
BigGroup
CHEN
SONI
40
HGBAC Commands & Privileges
Groups are accessed only through commands
• LIST group
-OR-
LIST group INDIRECT
Returns a result set consisting of the names of the users
and groups directly included in the group; if INDIRECT is
specified, it lists users and groups recursively included in
any subgroups.
It can be used by the owner of the group, or any user
who can exercise the LIST privilege on the group
• ADD name TO group
Adds a name (for a user or another group) to the group.
It can be used by the owner of the group, or any user
who can exercise the ADD privilege on the group
• REMOVE name FROM group
Remove a name (for a user or another group) from the
group, if it is present.
It can be used by the owner of the group, or any user
who can exercise the REMOVE privilege on the group
© Ellis Cohen 2002 - 2005
41
Comparing HRBAC vs HGBAC
Compare HGBAC and HRBAC. Are there
security problem that can only be solved
(or solved more easily) in one of them?
HGBAC does not have any equivalent to
enabling roles. How that could be added
to HGBAC?
If HRBAC allowed privileges with the
GRANT OPTION to be granted to roles,
would that change the comparison?
Suppose HGBAC did not have a GRANT
OPTION (so only the owner of a privilege
could grant it), how would the
comparison be affected?
© Ellis Cohen 2002 - 2005
42
Groups with
Selective Denial
(GSD)
© Ellis Cohen 2002 - 2005
43
A Selective Denial Problem
Suppose SCOTT owns Emps, and
wants to allow FLICKA to add users
who can select from Emps, but
wants to guarantee that regardless
of what FLICKA does, SMITH is not
able to access Emps (without
resorting to Views or Security
Policies)
Groups can be extended to directly
solve this selective denial problem.
© Ellis Cohen 2002 - 2005
44
Groups with Selective Denial (GSD)
A group contains a list of entries
Each entry contains a user name
(just like an ordinary group)
Entries can either be
– positive (granting) or
– negative (denying)
A user is supported by a group if
a positive entry for that user
appears below all negative
entries.
© Ellis Cohen 2002 - 2005
45
GSD Privileges
There are 3 privileges for GSD
groups:
• LIST, which allows a user to
get the entries of a group
• APPEND, which allows a user
to add an entry at the end of a
group
• CONTROL, which allows a user
to add or remove positive or
negative entries
© Ellis Cohen 2002 - 2005
46
GSD Example
In GSD, a group contains a list of users
MyGroup
SCOTT>
SCOTT>
SCOTT>
SCOTT>
SCOTT>
+ADAMS
+BLAKE
-SMITH
+JONES
+SMITH
CREATE GROUP MyGroup
GRANT SELECT ON Emps TO MyGroup
APPEND ADAMS, BLAKE TO MyGroup
APPEND -SMITH TO MyGroup
GRANT APPEND On MyGroup TO FLICKA
FLICKA> ADD JONES, SMITH TO SCOTT.MyGroup
Even though FLICKA appended SMITH to MyGroup,
SMITH is still unable to select in Emps,
because a negative entry for SMITH
appears before the positive entry.
© Ellis Cohen 2002 - 2005
47
General Selective Denial
IN the previous problem, once FLICKA
added a user to the group, FLICKA could
not remove that user.
Suppose SCOTT owns Emps, and wants to
allow FLICKA to add users (and removes
users that FLICKA added) who can select
from Emps, but wants to guarantee that
regardless of what FLICKA does, SMITH is
not able to access Emps (without
resorting to Views or Security Policies)
Hierarchical Groups with Selective Denial
can be used to solve this problem.
© Ellis Cohen 2002 - 2005
48
HGSD Example
– Grp1, BILL
+ Grp2
– Grp3
+ SAM
supports
• all users who are supported by
Grp2 (except for BILL and any user
supported by Grp1), and
• SAM (unless he is supported by
either Grp1 or Grp3)
© Ellis Cohen 2002 - 2005
49
Hierarchical Groups
with Selective Denial (HGSD)
A group contains a list of entries
Each entry contains a set of names of users
and other groups
Entries can either be positive (granting) or
negative (denying)
A user is supported by a group if the user is
included in a positive entry (directly as a
named user, or indirectly, if supported by
a named group) above all negative
entries that include the user (directly or
indirectly)
How does this solve the selective denial problem?
© Ellis Cohen 2002 - 2005
50
Selective Denial Solution
SCOTT> CREATE GROUP MyGroup
SCOTT> GRANT select ON Emps TO MyGroup
SCOTT> APPEND –SMITH TO MyGroup
SCOTT> CREATE GROUP FlickaGroup
SCOTT> APPEND FlickaGroup TO MyGroup
SCOTT> GRANT LIST, CONTROL, APPEND ON
FlickaGroup TO FLICKA
FLICKA> APPEND ADAMS, BLAKE, SMITH
TO SCOTT.FlickaGroup
MyGroup
-SMITH
FlickaGroup
ADAMS
BLAKE
SMITH
© Ellis Cohen 2002 - 2005
51
Access Control Lists
(ACLs)
© Ellis Cohen 2002 - 2005
52
Access Control Lists (ACLs)
Access Control Lists are very
similar to groups
– Like a group, an ACL lists users
who can exercise privileges
But, when using ACLs
– There is no GRANT command;
Privileges are never granted –
not to users, and not to ACLs
– Instead, every table, view, etc.
has a single ACL permanently
associated with it, which
determines who can use the
object and how
© Ellis Cohen 2002 - 2005
53
Simple ACLs
• Every table (or other object) has a
single ACL associated with it
• An ACL contains a list of entries
• Every entry contains
– A set of users
– A list of privileges (for the object
associated with the ACL).
ALL means all privileges for the object
• A user can exercise a privilege for a
table (or other object), if its ACL has an
entry which lists that user and that
privilege
© Ellis Cohen 2002 - 2005
54
Simple ACL Example
Specifies that SMITH & KLINE can query or update
the table in any way, and that SONI and ADAMS
can select from Emps, and update its sal field.
Emps' ACL
Emps
SMITH, KLINE:
ALL
SONI, ADAMS:
UPDATE(sal),
SELECT
…
Obviously, Emp's owner (e.g. SCOTT)
must be allowed to change Emps' ACL,
but how does SCOTT allow other users to change the ACL?
© Ellis Cohen 2002 - 2005
55
ACL-Specific Privileges
In general, the privileges in an ACL
apply to the object associated with an
ACL, but there are also privileges
which apply to the ACL itself!
– LISTACL, which allows a user to list the
entries of the ACL
– APPENDACL, which allows a user to add
a positive entry at the end of the ACL
– CONTROLACL, which allows a user to add
or remove positive or negative entries
from the ACL
© Ellis Cohen 2002 - 2005
56
ACL-Specific Privilege Example
Emps' ACL
Emps
SMITH, KLINE:
ALL,
APPENDACL
SONI, ADAMS:
UPDATE(sal),
SELECT
…
SMITH & KLINE can not only insert tuples into Emps,
but can append entries to the ACL itself.
© Ellis Cohen 2002 - 2005
57
Extended ACLs
We can also extend ACLs so they
have all the HGSD features
• Entries can either be positive
(granting) or negative (denying)
• Each entry can contain a set of
users and/or HGSD groups.
– Groups are still created by CREATE GROUP
– Each group now has an ACL which determines
who can list, append and control (make
arbitrary changes to) the group
– Privileges cannot be granted to groups. Groups
are strictly intended to be included within ACLs
and other groups.
© Ellis Cohen 2002 - 2005
58
Extended ACL Example
Emps might have the following ACL
+ SAM: LISTACL, CONTROLACL
+ BILL: INSERT
– NonEmpViewers: SELECT
– NonEmpUpdaters: INSERT, UPDATE, DELETE
+ BILL, SUE: SELECT, INSERT, UPDATE, DELETE
which will allow
– SAM to list and change the ACL,
– BILL to INSERT into Emps,
– BILL and SUE to SELECT from Emps, unless they
are in the group NonEmpViewers, and
– BILL to UPDATE or DELETE, and SUE to INSERT,
UPDATE or DELETE from Emps, unless they are in
the group NonEmpUpdaters
© Ellis Cohen 2002 - 2005
59
Hierarchical ACLs (HACLs)
Hierarchical ACLs allow the entries in an
ACL to list
– users,
– groups, or
– standalone ACLs
A standalone ACL can be created by the
command
CREATE ACL MyAcl
Like other objects, standalone ACLs have
their own ACLs which control access to
them, using the same privileges (LIST,
APPEND, CONTROL) as groups.
© Ellis Cohen 2002 - 2005
60
Using Standalone ACLs
A standalone ACL is not associated with an object; it
is simply meant to be included in other ACLs
(permanent or standalone). Its privileges are
included, restricted by those of the including entry.
Emps
Emps' ACL
MyAcl
SMITH, KLINE:
ALL
JONES:
ALL
SONI, MyAcl:
UPDATE(sal),
SELECT
BLAKE:
UPDATE(job),
SELECT
…
…
This effectively allows JONES to exercise the UPDATE(sal) and
SELECT privilege for Emps (JONES has ALL specified in MyAcl,
but this is restricted by the entry which includes MyAcl), and
only allows BLAKE to exercise the SELECT privilege for Emps
© Ellis Cohen 2002 - 2005
61
Comparing Mechanisms
HRBAC, HGBAC, and HACLs (with only
positive entries) provide similar
functionality.
What are the pros and cons of each?
How important is support for selective
denial (negative entries)? Could a
similar mechanism be added to
HRBAC?
Could security policies be added to
HGBAC and HACLs? Would that be
useful?
© Ellis Cohen 2002 - 2005
62
Security Domains
and
Operation-Based
Access Control
© Ellis Cohen 2002 - 2005
63
View-Based Access Control
Suppose only an employee's manager can change their salary?
CREATE VIEW EmpSalView AS
SELECT empno, ename, sal
WHERE mgr = AuthPkg.GetUser();
GRANT SELECT, UPDATE(sal) ON
ChangeSalView TO PUBLIC
© Ellis Cohen 2002 - 2005
64
Limiting Access with Views
A view (or cursor) can provide limited access to the
contents of a table
Exactly what is visible can even depend upon the
identity of the user
Security Domain
View
Client
Client cannot
access the table
directly
© Ellis Cohen 2002 - 2005
65
Security Domains
A group of database objects – tables,
views, triggers, etc. – can be
protected by a security domain.
These objects cannot be accessed
directly, but only through
a) views & cursors
b) stored DB operations
© Ellis Cohen 2002 - 2005
66
Limiting Access with
Stored DB Operations
Suppose SCOTT defines a function
IncrSal( anEmpno, pct ) which increases an
employee's salary by a specified pct
If TOMMY is connected, TOMMY can try to execute
that function by doing
TOMMY> EXECUTE SCOTT.IncrSal( 3047, 10 )
This will only be allowed if SCOTT has granted
TOMMY the privilege to EXECUTE IncrSal
SCOTT> GRANT EXECUTE ON IncrSal TO TOMMY
PROCEDURE IncrSal( anEmpno int, pct number ) IS
BEGIN
UPDATE Emps SET sal = sal * pct WHERE empno = anEmpno;
END;
© Ellis Cohen 2002 - 2005
67
Stored DB Operations Limit Access
Stored DB operations (i.e. procedures & functions)
can straddle security domains.
They can be called from outside the domain,
but then execute inside the domain
(so the operation can actually
modify the table!)
Security Domain
SCOTT
Security Domain
TOMMY
IncrSal
Client
Client cannot
access the table
directly
Emps
© Ellis Cohen 2002 - 2005
68
Operation-Based Access Control
Both views and stored DB operations implement
fine-grained access control in similar ways
The PL/SQL code for IncrSal is
PROCEDURE IncrSal( anEmpno int, pct number ) IS
BEGIN
-- add code to check that the
-- current user is the manager of anEmpno
UPDATE Emps SET sal = sal * pct
WHERE empno = anEmpno;
END;
Add the access control code
using PL/SQL or pseudocode.
AuthPkg.GetUser returns the employee #
of the current user
Emps.mgr holds the employee number of
an employee's manager
© Ellis Cohen 2002 - 2005
69
IncrSal
PROCEDURE IncrSal( anEmpno int, pct number ) IS
BEGIN
UPDATE Emps SET sal = sal * pct
WHERE empno = anEmpno
AND mgr = AuthPkg.GetUser();
END;
-orPROCEDURE IncrSal( anEmpno int, pct number ) IS
themgr int;
BEGIN
SELECT mgr INTO themgr FROM Emps
WHERE empno = anEmpno;
IF themgr <> AuthPkg.GetUser() THEN
raise error;
END;
UPDATE Emps SET sal = sal * pct
WHERE empno = anEmpno;
END;
© Ellis Cohen 2002 - 2005
70
Issue: Operation-Based vs
View-Based Access Control
DB Operations:
Query Operations return information, but
do not change the database
Action/Modification operations change
the contents of the database
Access Control Approaches:
View-Based: Uses views (and cursors) to
limit access to tables
Operation-Based: Uses stored DB
operations to limit access to tables
Which access control approach can be used / is best
for query operations? for modification operations?
© Ellis Cohen 2002 - 2005
71
Answer: Operation-Based vs
View-Based Access Control
Use View-Based access control for query
operations
– This allows the caller to define complex queries
based on one or more views, which can be
optimized by the DB query optimizer
Use Operation-Based access control for
modification operations
– Provides more convenient interface
(multiplying sal by a pct vs setting new salary)
– Allows operations to invisibly perform sideeffects, e.g. saving intermediate state to
increase performance
– Limits modifications to enforce constraints
© Ellis Cohen 2002 - 2005
72
Constrained Modification
Operation-based access control can be used to
limit the kind of changes allowed.
Suppose we did not want to allow users (granted execute on
IncrSal) to be able to arbitrarily change an individual employee's
salary
We instead wanted to ensure that all employees have their salaries
increased uniformly!
Rewrite IncrSal as
PROCEDURE IncrSal( pct number ) IS
BEGIN
UPDATE Emps SET sal = sal * pct
WHERE mgr = AuthPkg.GetUser();
END;
© Ellis Cohen 2002 - 2005
73
Solving Protection Problems with
Operation-Based Access Control
Suppose SCOTT wants
a) to be able to delegate to FLICKA the ability to
determine who should be granted the privilege to
SELECT on NameAddrView, but
b) doesn't want FLICKA to be able to delegate this
privilege on to other users.
How might this be enforced?
HINT: You can define a procedure whose code
grants a privilege to some user
HINT: Assume AuthPkg.getDbId( empno ) gets
the database id of the specified employee
© Ellis Cohen 2002 - 2005
74
Granting to Employees
SCOTT> CREATE PROCEDURE GrantIt( anEmpno int )
IS BEGIN
GRANT SELECT on NameAddrView
TO AuthPkg.GetDbId( anEmpno );
END;
SCOTT> GRANT EXECUTE On GrantIt TO FLICKA;
Note: the actual PL/SQL code for GrantIt is a bit more
complicated, since GRANT is not a PL/SQL command
© Ellis Cohen 2002 - 2005
75
Domain Execution Models
A stored DB operation can be created with
• Definer rights: the schema and privileges in force
during execution of the operation are those of the
user who owns the operation (also called domain
switching). Use this to define public operations.
PROCEDURE JustDoIt (…)
This is the
AUTHID DEFINER IS …
default in
PROCEDURE JustDoIt (…) IS
Oracle!
• Invoker rights: the schema and privileges in force
during execution of the operation are those of the
caller.
PROCEDURE JustDoIt (…)
AUTHID CURRENT_USER IS …
When would it be useful to define
invoker rights procedures
© Ellis Cohen 2002 - 2005
76
Use of Invoker Rights Operations
• Private Operations
– There is no reason to incur the (potential) overhead
of domain switching for private operations, since
the caller is always in the same domain
– In addition, if by mistake, an unauthorized user
was granted execute permission for this operation,
it wouldn't be very useful, since the operation
would execute with the caller's
(non-)privileges on the objects it would try to
access.
• Utility Operations
– Mathematical library function
– Utilities that operate on the caller's schema – e.g.
PrintTableNicely( tblnam ). SERIOUS WARNING:
Because these execute in the caller's schema, the
caller must be certain that the (author of the)
operation is trustworthy!
© Ellis Cohen 2002 - 2005
77
Packaged DB Operations
Some databases allow/require stored DB operations
to be grouped into packages, and then grant
EXECUTE privileges (& define the domain
execution model) for packages as a whole
Suppose SCOTT defines a package EmpPkg, which
includes a variety of operations, incluidng
IncrSal(pct )
If TOMMY is connected, TOMMY can try to execute
that function by doing
TOMMY> EXECUTE SCOTT.EmpPkg.IncrSal( 10 )
This will only be allowed if SCOTT has granted
TOMMY the privilege to EXECUTE EmpPkg
SCOTT> GRANT EXECUTE ON EmpPkg TO TOMMY
© Ellis Cohen 2002 - 2005
78
Dynamic Security
© Ellis Cohen 2002 - 2005
79
Overview of DAC Mechanisms
Basic DAC
Dynamic Views
Security Predicates & Policies
RBAC/HRBAC
GBAC/HGBAC
GSD/HGSD
ACLs/HACLs
Capabilities (to be discussed with OODBs)
Security Domains
Can be used for dynamic security:
simulation of arbitrary DAC mechanisms
© Ellis Cohen 2002 - 2005
80
DAC Mechanisms
Every DAC Mechanism consists of
– Operations which change the access control state
– Access control checks that check the access
control state to constrain access to DB objects
• For built-in mechanisms
– Operations which affect the access control state
are implemented by commands:
e.g. GRANT SELECT ON Emps To JOE
– Access checks are implemented directly by the
database system when accessing tables
– Access control is implemented by metadata
tables maintained by the DB (updated on
GRANT/REVOKE), and checked on every access
© Ellis Cohen 2002 - 2005
81
DB as a "Security Domain"
The DB implementation is itself like a security domain
• It hides/protects the internal representation of tables
• It checks its access control state on access operations
Database
GRANT
Modifies
Access Control
State
REVOKE
UPDATE
SELECT
Modifies
Emps
Checks
Access Control
State
Emps
© Ellis Cohen 2002 - 2005
Access
Control
State
82
Dynamic Security
Dynamic Security is the implementation of arbitrary
security mechanisms using Security Domains
How are non-built-in mechanisms implemented?
– A user-defined security domain needs to be used to
implement the mechanism
– The mechanism's access control state will be
implemented using private tables created in the
security domain
– Operations which affect the access control state are
implemented by stored DB operations defined by the
security domain
– Tables protected by the mechanism are supported by
views, stored DB operations, or security policies
which check the access control state
How might SCOTT implement Primitive ACL's to
control access to SCOTT's tables?
© Ellis Cohen 2002 - 2005
83
ACL Implementation Overview
SCOTT would
• Define table(s) to maintain ACLs (e.g.
AclPriv)
• Define public operations ListAcl,
AppendToAcl, RemoveFromAcl
• Protect all access to SCOTT's known
tables (e.g. Emps) by views, stored
operations, or security predicates, which
would call the private EmpAcl function
CheckAcl to check the ACL tables and
determine if the user had the right to
perform the query or other operation
© Ellis Cohen 2002 - 2005
84
Some ACL Implementation Details
TABLE AccPrivs( tblnam, usr, priv ) …
– tracks the privileges a user has for a table
PROCEDURE CheckPriv( aTblnam, aUsr, aPriv )
– returns true if a tuple is returned from
SELECT * FROM AccPrivs
WHERE tblnam = aTblnam
AND usr = aUsr AND aPriv = priv
PROCEDURE AppendPriv( aTblnam, aUsr, aPriv )
IF CheckPriv( aTblnam, USER, 'APPENDACL' ) OR
CheckPriv( aTblnam, USER, 'CONROLACL' )
THEN
INSERT INTO AccPrivs VALUES (aTblnam, aUsr, aPriv )
VIEW EmpsView
SELECT * FROM Emps
WHERE CheckPriv( 'Emps', USER, 'SELECT' )
GRANT SELECT ON EmpsView TO PUBLIC
All implemented by SCOTT.
This is pseudocode; the actual code is slightly more complex
© Ellis Cohen 2002 - 2005
85
User-Based
Access Control
in Multi-Tier
Applications
© Ellis Cohen 2002 - 2005
86
Web-Based 3-Tier Architecture
Handles
formatting &
overall page
navigation
Java
Servelet
Web
Browser
Handles complex
queries, updates &
integrity maintenance
J
D
B
C
Database
Server
Web or
Application
Server
Implements User
Operations
Presentation
Tier
Stored
DB Operations
Middle Tier
© Ellis Cohen 2002 - 2005
Implements
DB Operations
Data Tier
87
UI's and Web Services
Web
Service
Client
Distributed
Application
Environment
Interactive
Client
Web
Browser
Presentation
Tier
SOAP
Web
Service
Interface
User
Operations
J
D
B
C
Database
Server
UI
Management
Web or
Application
Server
Middle Tier
© Ellis Cohen 2002 - 2005
Data Tier
88
The Multi-Tier Problem
In web-based or other multi-tier
applications, the user does not
interact directly with the database,
but with an intermediate
application.
How can database-supported access
control be implemented in this
situation?
 The intermediate application must
maintain a separate connection to
the database on behalf of each of
its users.
© Ellis Cohen 2002 - 2005
89
User-Based Access Control
Each end user using an application has their
own database user id. When logging in to
the application, the end user either
– provides the application with an existing userspecific connection to the database, or
– identifies (authenticates) itself to the
application, which then creates a user-specific
connection to the database on the user's
behalf.
The DBA protects the organization's data by
creating it in a special security domain (e.g.
SCOTT or EmpDB)
– The DBA creates views and stored DB
operations and grants access as needed to
users directly or through roles
© Ellis Cohen 2002 - 2005
90
User-Based Security Domains
Web
Browser
JOE's
Security Domain
Stored
DB Operations
App Server
/Java
Servelet
Web
Browser
Presentation
Tier
SAM's
Security Domain
Middle Tier
© Ellis Cohen 2002 - 2005
Database
Server
EmpDB's
Security Domain
Data Tier
91
Connection Cost
Database connections have high
overhead.
It is too expensive for applications to
maintain a separate connection to
the database on behalf of each
active user.
This approach is only feasible if
multiple "sessions" or virtual
connections can share a single
database connection.
© Ellis Cohen 2002 - 2005
92
Connections & Sessions
Some databases (e.g. Oracle) can support
multiple sessions within a single connection
• A Web/App server must itself first connect as a
normal database user.
• The Web/App server can then create multiple
sessions over the connection
– Each request it sends to the DB server is
automatically tagged with the session the
request is to be associate with
• Each session is associated with a database user
– Either a password must be provided for the session
database user when setting up the session, or
some shared authentication model must be used.
• This allows a USER-BASED access control mechanism
to be used (like the ones we have been describing)
© Ellis Cohen 2002 - 2005
93
Session Protection
Before a Web/App server (logged in
a database user in its own right)
can create a session on behalf of a
user, it must have a privilege to do
so
This privilege must be granted to the
Web/App server by the DBA
(or some other user with the privilege
to make such grants)
When granting a Web/App server the
privilege to create a session on
behalf of a particular user, it may
be possible to restrict the roles that
user can enable.
© Ellis Cohen 2002 - 2005
94
Application-Based
Access Control
© Ellis Cohen 2002 - 2005
95
Application-Based Access Control
The middle-tier application needs to
be trusted
– to authenticate users
– To use the correct DB
connection/session to make a DB
requests to implement a user's request
If the middle-tier application must be
trustworthy anyway, why shouldn't it
implement access control directly
making only minimal use of
database-provided access control
mechanisms?
© Ellis Cohen 2002 - 2005
96
Connecting to the Database
The organization's data is still placed in a
separate schema (e.g. EmpDB)
The middle-tier application (as well as the
DBA, but not other users) is now able to
connect directly to that schema. Either
– The middle tier-application knows (or can
securely obtain) the password for the schema
– The middle-tier application can (in some other
way) authenticate itself to the database as a
legitimate user of the schema.
The middle-tier application then directly
executes the code to implement security
policies
© Ellis Cohen 2002 - 2005
97
Single Application User
EmpDB Security Domain
Authenticates
user
Java
Servelet
Web
Browser
Presentation
Tier
J
D
B
C
Stored
DB Operations
Database
Server
Web or
Application
Server
Middle Tier
© Ellis Cohen 2002 - 2005
Data Tier
98
Application Login IDs
The application is itself
responsible for managing user
ids, and for authenticating users.
If users correspond to database
entities (e.g. employees) then
the application must maintain
(via the database, LDAP, etc.)
the mapping between its user
ids and the primary keys of the
database entities (e.g. empno)
© Ellis Cohen 2002 - 2005
99
Application-Based Example
Suppose a user invokes an operation to
change the salary of an employee
The security policy requires that the current
user be that employee's manager.
The application code must
– get the employee number corresponding to the
current user
– check if the current user is the manager of the
specified employee
– If so, change the salary
This can be done through separate DB
operations or through a single request:
UPDATE Emps
SET sal = theSpecifiedSalary
WHERE empno = theSpecifiedEmpno
AND mgr = getEmpnoOfUser( getCurrentUserId() )
– getCurrentUserId() is not USER
– It’s the application user; USER is always EmpDB
© Ellis Cohen 2002 - 2005
100
User vs Application-Based Access Control
User-Based Access Control
• Either views or stored DB operations had to be
defined
• Privileges to use the view or execute the
procedure needed to be granted to users
• This made it unnecessary to grant users access to
the underlying tables
Application-Based Access Control
• Views and stored DB operation do not need to be
defined.
• The application is trusted to access the underlying
tables directly
• Views and stored DB operations can be defined
for convenience
• Less secure and cannot be used with Mandatory
Access Control
© Ellis Cohen 2002 - 2005
101
Application Domains
A core database may be used by different
applications, each which may have
different kinds of limited access to the
data
Define a security domain for each
application
The DBA defines views and packages and
grants privileges as needed to each
application domain
Each application still authenticates its own
users
© Ellis Cohen 2002 - 2005
102
Multiple Application Domains
EmpApp
EmpDB
Does Own User
Authentication
HRApp
Does Own User
Authentication
© Ellis Cohen 2002 - 2005
Tables
103
Mandatory
Access Control
Mechanisms
(MAC)
Also Called Lattice-Based
Access Control (LBAC)
© Ellis Cohen 2002 - 2005
104
Trojan Horse Problem
Trojan Horse
Executable code that has undesirable side effects
unknown to the user of the code
Suppose
SCOTT creates an invoker-rights DataMine procedure
which allows users mine to mine tables of their
information (specified as parameters)
[Why can't DataMine be definer-rights?]
SCOTT grants EXECUTE on DataMine to PUBLIC and
encourages everyone to use it for data mining
However
SCOTT creates a StolenInfo table
and grants INSERT on StolenInfo to PUBLIC
The DataMine procedure copies all info from the
tables mined into StolenInfo
Stealing Top Secret Information
If SCOTT has no clearance, and DataMine is used by
someone to mine top secret data
 potentially serious security breach
© Ellis Cohen 2002 - 2005
105
Mandatory Access Control
Purpose
Limit information flow via access control
Prevent flow of information from higher to lower
security level
Mechanism
– All data is tagged with its security level (could
be at table, row or field level)
– Simple Security Property: User can never read
data at higher security level than user's
clearance level
– *-Property: Data can be modified only if its
level is no lower than the user's security level
(Prevents DataMine writing into StolenInfo)
– Newly created data (new table, or inserted row
if row-level security is supported) is created at
the user's security level
How does this solve the Trojan Horse Problem?
© Ellis Cohen 2002 - 2005
106
Questions about MAC
Suppose, each user's session has a security level,
which starts out at the lowest security level, and
increases, so it is at least as high as any object
read during the session. Suppose that a user can
write into an object only if the object's security
level is at least as high as the user's current
session security level. Is that OK?
Suppose we allow a user to arbitrarily increase the
security level of security-tagged data, so long as
the user's security level is at least as high as the
original level of the data. Is that OK?
In MAC, a user can write into an object at a higher
security level. Is that really OK?
© Ellis Cohen 2002 - 2005
107
Row-Level Security and
Covert Information Flow
BaseEquipment
equipid equipname count class
0736
Jeep
32
C
0877
Nuclear
Missile
4
S
…
…
…
…
Visibility (Automatic Views)
• User with S (secret) clearance
will see both rows
• User with C (classified)
clearance will only see Jeeps
• User with U (unclassified)
clearance will see no rows
Suppose user with U clearance tries to insert a row with
equipid 0877 (nuclear missile) [it will have class U]
• Allowing INSERT violates primary key constraint
• Disallowing INSERT covertly tells U class user that
nuclear missiles are on the base
What are some possible solutions?
© Ellis Cohen 2002 - 2005
108
Row-Level Security Solution
• Always include tuples for
secret & classified data,
even if the count is 0
• Change the primary key to
equipid + class
(This is called Polyinstantiation)
The point is NOT that it is hard to solve this problem.
The point is that if you are NOT careful when using
access control mechanisms to limit information flow,
covert information flow (or small amounts of
information that may nonetheless be very serious)
may be possible!
© Ellis Cohen 2002 - 2005
109
Statistical Database
Access
© Ellis Cohen 2002 - 2005
110
Privacy &
Statistical Database Access
Suppose
A database with information about
individuals is considered private &
confidential
However, users are allowed to have
statistical access to information for
research purposes (via aggregate
functions -- COUNT, AVG, MIN, etc.)
using a special application that limits
the queries allowed
Such applications, unless they are
careful, can compromise privacy
© Ellis Cohen 2002 - 2005
111
Allowable Queries
For example, consider access to
census information. Consider the
following two queries.
SELECT avg(yrsInPrison)
WHERE state = "MA"
SELECT avg(yrsInPrison)
WHERE zipcode = "02445"
AND addr = "757 University Rd"
Which of these should be allowable queries?
Why?
© Ellis Cohen 2002 - 2005
112
Aggregate Size
SELECT avg(yrsInPrison)
WHERE state = "MA"
Should be allowable because it covers too
many individuals to find out anything
about a particular individual. It's a
classic public policy query.
SELECT avg(yrsInPrison)
WHERE zipcode = "02445"
AND addr = "757 University Rd"
Should not be allowable because it covers
too few people. It violates privacy.
To safeguard privacy, is it adequate to limit queries
based on the # of tuples being aggregated?
© Ellis Cohen 2002 - 2005
113
Consider These Queries
SELECT count(*), avg(yrsInPrison)
WHERE state = "MA"
SELECT count(*), avg(yrsInPrison)
WHERE state = "MA"
AND (zipcode != "02445" OR
addr != "757 University Rd")
Both queries consider over a million people as part of
the query.
But what can you learn from this query?
© Ellis Cohen 2002 - 2005
114
Inferring Private Information
Call the result of this query k1 and a1
SELECT count(*), avg(yrsInPrison)
WHERE state = "MA"
Call the result of this query k2 and a2
SELECT count(*), avg(yrsInPrison)
WHERE state = "MA"
AND (zipcode != "02445" OR
addr != "757 University Rd")
Then (k1*a1 + k2*a2)/(k1 + k2)
gives us the results of the query
we should NOT have been allowed to do!
How can we prevent this problem?
© Ellis Cohen 2002 - 2005
115
Approaches & Dangers
•Limit aggregate queries to ones which
operate on a minumum number of rows
Use multiple queries whose overlap is a single row
•Use an inferencing engine to determine
what a set of queries can infer
Extremely hard problem
Suppose different users collaborate
•Randomly alter underlying data for each
query
Can make it difficult to make accurate inferences
Has only a minor effect on true statistical queries
© Ellis Cohen 2002 - 2005
116