1

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

© Ellis Cohen 2002 - 2005 2

Overview of LectureSecurity Predicates & PoliciesRole-Based Access Control (RBAC) Solving Security Problems with Roles, Dynamic

Views, and Security PredicatesHierarchical RBACGroup-Based Access Control (GBAC) Groups with Selective Denial (GSD) Access Control Lists (ACLs)Security Domains &

Operation-Based Access ControlDynamic SecurityUser-Based Access Control

in Multi-Tier ApplicationsApplication-Based Access ControlMandatory Access Control Mechanisms (MAC)Statistical Database Access

© Ellis Cohen 2002 - 2005 3

Security Predicates& Policies

© Ellis Cohen 2002 - 2005 4

Security Predicate Mechanism

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

Security predicate mechanisms provide fine-grained access control

without the need to explicitly define views.

© Ellis Cohen 2002 - 2005 5

Security Predicate Example

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.EmpsWHERE empno = SCOTT.AuthPkg.GetUser();

Suppose SCOTT wants to allow a user to only access their own row of the Emps table

© Ellis Cohen 2002 - 2005 6

Security Policies

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

Security Policies generalize Security Predicates

© Ellis Cohen 2002 - 2005 7

Security Policy ExampleSCOTT> 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.EmpsWHERE 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 8

Security Policy SolutionSCOTT> 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.EmpsSET job = 'CLERK WHERE ename = 'JONES'

effectively rewritten as

TOMMY> UPDATE SCOTT.EmpsSET job = 'CLERK'WHERE ename = 'JONES' AND SCOTT.AuthPkg.GetUser() IS NOT NULL AND (SELECT job FROM SCOTT.Emps WHERE empno = SCOTT.AuthPkg.GetUser()) = 'DEPTMGR'

Suppose this updated sal as well

as job?

© Ellis Cohen 2002 - 2005 9

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 10

Role-Based Access Control

(RBAC)

© Ellis Cohen 2002 - 2005 11

Groups of Privileges & UsersRoles provide a mechanism which simplify

granting the same set of privileges to a group of users

HARRY

ADAMS

select on Emps

select on Depts

Consider the group of usersAll play the same role with respect to a DB application and need the same privileges

Consider the group of privilegesWe'd like to bundle them up together to be given as a group to different users

SCOTT> GRANT SELECT on Emps TO HARRY, ADAMSSCOTT> GRANT SELECT on Depts TO HARRY, ADAMS

© Ellis Cohen 2002 - 2005 12

Basic RBACBasic 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

InfoRole

select on Emps

select on Depts

Privileges Role Users

HARRY

ADAMS

SCOTT> CREATE ROLE InfoRoleSCOTT> GRANT SELECT on Emps TO InfoRoleSCOTT> GRANT SELECT on Depts TO InfoRoleSCOTT> GRANT InfoRole TO HARRY, ADAMS

© Ellis Cohen 2002 - 2005 13

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

InfoRole

select on Emps

select on Depts

Privileges Role Users

HARRY

ADAMS

Somewhat similar to "capability lists"

© Ellis Cohen 2002 - 2005 14

Revoking Privileges from Roles

A user U can revoke a privilegefrom 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 15

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 Users

Similar to OS user groups

InfoRole

select on Emps

select on Depts

HARRY

ADAMS

© Ellis Cohen 2002 - 2005 16

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 OptionSCOTT> CREATE ROLE DeveloperSCOTT> GRANT Developer TO FLICKA

WITH ADMIN OPTION

FLICKA> GRANT Developer TO MERCURIO

© Ellis Cohen 2002 - 2005 17

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 18

Simulating Centralized Administration of Privileges

SCOTT> CREATE ROLE SelectEmpsSCOTT> GRANT SELECT On Emps

TO SelectEmpsSCOTT> GRANT SelectEmps

TO FLICKA, SMITH, JONESWITH 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 19

Simulating Sub-Centralized Administration of Privileges

SCOTT> CREATE ROLE SmithSelectEmpsSCOTT> GRANT SELECT On Emps TO SmithSelectEmpsSCOTT> GRANT SmithSelectEmps TO SMITH

WITH ADMIN OPTION

SCOTT> CREATE ROLE FlickaSelectEmpsSCOTT> GRANT SELECT On Emps TO FlickaSelectEmpsSCOTT> GRANT FlickaSelectEmps TO FLICKA

WITH ADMIN OPTION

FLICKA> GRANT FlickaSelectEmps TO DILIPWITH ADMIN OPTION

FLICKA> GRANT FlickaSelectEmps TO CHUWITH 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 20

Enabling RolesGranting a role to a user does not

automatically allow the user to exercise its privileges

Users must enable rolesEnsures that a user only has privileges relevant

to the role they are exercising

Enabling roles (e.g. by harry)SCOTT> grant InfoRole to HARRYHARRY> set role InfoRoleHARRY> 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 21

Questions about RolesRole names in Oracle are global rather than schema-

specific (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 22

Solving Security Problems with Roles,

Dynamic Views & Security Predicates

© Ellis Cohen 2002 - 2005 23

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)

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.

© Ellis Cohen 2002 - 2005 24

Role-Based Access Control

SCOTT> CREATE ROLE DeptMgr

SCOTT> GRANT DeptMgr TO Jones, Blake, Clark – the three department managers

SCOTT> CREATE VIEW NameAddrView ASSELECT ename, addr FROM Emps

SCOTT> GRANT SELECT ON NameAddrViewTO 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 25

Trigger-Based Role Memebership

SCOTT> CREATE TRIGGER AddMgrAFTER INSERT, UPDATE OF job ON EmpsFOR EACH ROWWHEN (new.job = 'DEPTMGR')GRANT Manager TO AuthPkg.GetDbId( new.empno )

SCOTT> CREATE TRIGGER DelMgrAFTER DELETE, UPDATE OF job ON EmpsFOR EACH ROWWHEN (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 26

Using Dynamic Views

SCOTT> CREATE VIEW NameAddrView ASSELECT ename, addr FROM EmpsWHERE (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 27

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 28

Targeted Security Policies

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.

Instead of granting privileges on different views of a table to various roles, we can extend security policies

to be user or role-specific

© Ellis Cohen 2002 - 2005 29

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 30

Targeted Security Policy Example

SCOTT> ASSOCIATE 'empno = AuthPkg.GetUser()'WITH Emps FOR SELECTTARGET 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.EmpsWHERE empno = SCOTT.AuthPkg.GetUser() OR mgr = SCOTT.AuthPkg.GetUser()

Suppose any employee can see their own Emps entry, and a manager can see/update salaries of their employees

© Ellis Cohen 2002 - 2005 31

Hierarchical RBAC(HRBAC)

© Ellis Cohen 2002 - 2005 32

Hierarchical RBAC (HRBAC)

select

on dept

select

on emp

Developers

Researchers

InfoRole

Techies

SONI

ADAMS

CLARK

JONES

BLAKE

Roles can be granted to other roles

© Ellis Cohen 2002 - 2005 33

Roles as Hierarchical Groups of Privileges

select

on dept

select

on emp

Developers

Researchers

InfoRole

Techies

SONI

ADAMS

CLARK

JONES

BLAKE

© Ellis Cohen 2002 - 2005 34

Roles as Hierarchical Groups of Users

select

on dept

select

on emp

Developers

Researchers

InfoRole

Techies

SONI

ADAMS

CLARK

JONES

BLAKE

© Ellis Cohen 2002 - 2005 35

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 36

Mechanisms & Design DecisionsAfter 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 37

Group-BasedAccess Control

(GBAC)

© Ellis Cohen 2002 - 2005 38

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 39

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 40

GBAC vs HGBAC

ADAMSBLAKEJONES

MyGroupIn GBAC, a group contains a list of usersSCOTT> CREATE GROUP MyGroupSCOTT> GRANT INSERT ON Emps TO MyGroupSCOTT> ADD ADAMS TO MyGroupSCOTT> GRANT ADD On MyGroup TO FLICKAFLICKA> ADD BLAKE, JONES TO SCOTT.MyGroup

In HGBAC, a group contains a list of users and/or other groupsSCOTT> CREATE GROUP BigGroupSCOTT> GRANT SELECT ON Emps TO BigGroupSCOTT> ADD CHEN TO BigGroupSCOTT> ADD MyGroup TO BigGroupSCOTT> GRANT ADD On BigGroup TO PORTERPORTER> ADD SONI TO SCOTT.BigGroup

CHEN

SONI

BigGroup

© Ellis Cohen 2002 - 2005 41

HGBAC Commands & PrivilegesGroups are accessed only through commands

• LIST group -OR- LIST group INDIRECTReturns 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 groupAdds 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 groupRemove 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 42

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 43

Groups withSelective Denial

(GSD)

© Ellis Cohen 2002 - 2005 44

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 45

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 46

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 47

GSD Example

+ADAMS+BLAKE-SMITH+JONES+SMITH

MyGroupIn GSD, a group contains a list of usersSCOTT> CREATE GROUP MyGroupSCOTT> GRANT SELECT ON Emps TO MyGroupSCOTT> APPEND ADAMS, BLAKE TO MyGroupSCOTT> APPEND -SMITH TO MyGroupSCOTT> 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 48

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 49

HGSD Example

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)

– Grp1, BILL+ Grp2– Grp3+ SAM

© Ellis Cohen 2002 - 2005 50

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 51

Selective Denial SolutionSCOTT> CREATE GROUP MyGroupSCOTT> GRANT select ON Emps TO MyGroupSCOTT> APPEND –SMITH TO MyGroupSCOTT> CREATE GROUP FlickaGroupSCOTT> APPEND FlickaGroup TO MyGroupSCOTT> GRANT LIST, CONTROL, APPEND ON

FlickaGroup TO FLICKA

FLICKA> APPEND ADAMS, BLAKE, SMITHTO SCOTT.FlickaGroup

ADAMSBLAKESMITH

FlickaGroup

-SMITH

MyGroup

© Ellis Cohen 2002 - 2005 52

Access Control Lists(ACLs)

© Ellis Cohen 2002 - 2005 53

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 54

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 55

Simple ACL Example

Emps SMITH, KLINE:ALL

SONI, ADAMS:UPDATE(sal),SELECT

…

Emps' ACL

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.

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 56

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 57

ACL-Specific Privilege Example

Emps SMITH, KLINE:ALL,APPENDACL

SONI, ADAMS:UPDATE(sal),SELECT

…

Emps' ACL

SMITH & KLINE can not only insert tuples into Emps,but can append entries to the ACL itself.

© Ellis Cohen 2002 - 2005 58

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 59

Extended ACL ExampleEmps 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 60

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 61

Using Standalone ACLsA 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 SMITH, KLINE:ALL

SONI, MyAcl:UPDATE(sal),SELECT

…

Emps' ACL

JONES:ALL

BLAKE:UPDATE(job),SELECT

…

MyAcl

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 62

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 63

Security Domainsand

Operation-BasedAccess Control

© Ellis Cohen 2002 - 2005 64

View-Based Access Control

CREATE VIEW EmpSalView ASSELECT empno, ename, salWHERE mgr = AuthPkg.GetUser();

GRANT SELECT, UPDATE(sal) ON ChangeSalView TO PUBLIC

Suppose only an employee's manager can change their salary?

© Ellis Cohen 2002 - 2005 65

Limiting Access with Views

ClientClient cannot

access the table directly

View

Security Domain

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

© Ellis Cohen 2002 - 2005 66

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 67

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 ) ISBEGIN UPDATE Emps SET sal = sal * pct WHERE empno = anEmpno;END;

© Ellis Cohen 2002 - 2005 68

Stored DB Operations Limit Access

ClientClient cannot

access the table directly

IncrSal

Security DomainSCOTT

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 DomainTOMMY

Emps

© Ellis Cohen 2002 - 2005 69

Operation-Based Access Control

The PL/SQL code for IncrSal is

PROCEDURE IncrSal( anEmpno int, pct number ) ISBEGIN

-- 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

Both views and stored DB operations implementfine-grained access control in similar ways

© Ellis Cohen 2002 - 2005 70

IncrSalPROCEDURE IncrSal( anEmpno int, pct number ) ISBEGIN UPDATE Emps SET sal = sal * pct

WHERE empno = anEmpno AND mgr = AuthPkg.GetUser();

END; -or-

PROCEDURE 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 71

Issue: Operation-Based vs View-Based Access Control

DB Operations:Query Operations return information,

but do not change the databaseAction/Modification operations change

the contents of the databaseAccess 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 72

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 side-

effects, e.g. saving intermediate state to increase performance

– Limits modifications to enforce constraints

© Ellis Cohen 2002 - 2005 73

Constrained Modification

PROCEDURE IncrSal( pct number ) ISBEGIN UPDATE Emps SET sal = sal * pct

WHERE mgr = AuthPkg.GetUser();END;

Operation-based access control can be used tolimit 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

© Ellis Cohen 2002 - 2005 74

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 userHINT: Assume AuthPkg.getDbId( empno ) gets

the database id of the specified employee

© Ellis Cohen 2002 - 2005 75

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 76

Domain Execution ModelsA 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 (…) AUTHID DEFINER IS …PROCEDURE JustDoIt (…) IS

• Invoker rights: the schema and privileges in force during execution of the operation are those of the caller.

PROCEDURE JustDoIt (…) AUTHID CURRENT_USER IS …

This is the default in Oracle!

When would it be useful to define invoker rights procedures

© Ellis Cohen 2002 - 2005 77

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 78

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 79

Dynamic Security

© Ellis Cohen 2002 - 2005 80

Overview of DAC Mechanisms

Basic DACDynamic ViewsSecurity Predicates & PoliciesRBAC/HRBACGBAC/HGBACGSD/HGSDACLs/HACLsCapabilities (to be discussed with OODBs)

Security DomainsCan be used for dynamic security: simulation of arbitrary DAC mechanisms

© Ellis Cohen 2002 - 2005 81

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 82

DB as a "Security Domain"

GRANTDatabase

Emps

REVOKE

UPDATE

SELECT

AccessControl

State

ModifiesAccess Control

State

ChecksAccess Control

State

ModifiesEmps

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

© Ellis Cohen 2002 - 2005 83

Dynamic Security

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?

Dynamic Security is the implementation of arbitrary security mechanisms using Security Domains

© Ellis Cohen 2002 - 2005 84

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 85

Some ACL Implementation DetailsTABLE 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 EmpsViewSELECT * 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 86

User-BasedAccess Control

in Multi-TierApplications

© Ellis Cohen 2002 - 2005 87

Web-Based 3-Tier Architecture

DatabaseServer

WebBrowser

Web or Application

Server

JavaServelet

JDBC

Presentation Tier

Data TierMiddle Tier

Stored DB Operations

Handles formatting & overall page navigation

Handles complex queries, updates &

integrity maintenance

Implements DB Operations

Implements User Operations

© Ellis Cohen 2002 - 2005 88

UI's and Web Services

DatabaseServer

WebBrowser

Web or Application

Server

UserOperations

JDBC

Presentation Tier

Data TierMiddle Tier

UIManagement

WebService

Interface

Web ServiceClient

DistributedApplication

Environment

SOAP

InteractiveClient

© Ellis Cohen 2002 - 2005 89

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 90

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 user-specific 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 91

User-Based Security Domains

DatabaseServer

WebBrowser

App Server/Java

Servelet

Presentation Tier

Data TierMiddle Tier

Stored DB Operations

EmpDB's Security Domain

JOE's Security Domain

WebBrowser

SAM's Security Domain

© Ellis Cohen 2002 - 2005 92

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 93

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 94

Session ProtectionBefore 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 95

Application-BasedAccess Control

© Ellis Cohen 2002 - 2005 96

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 97

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 98

Single Application User

DatabaseServer

WebBrowser

Web or Application

Server

JavaServelet

JDBC

Presentation Tier

Data TierMiddle Tier

Stored DB Operations

Authenticates user

EmpDB Security Domain

© Ellis Cohen 2002 - 2005 99

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 100

Application-Based ExampleSuppose a user invokes an operation to change the salary of an employeeThe 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 EmpsSET sal = theSpecifiedSalaryWHERE empno = theSpecifiedEmpnoAND mgr = getEmpnoOfUser( getCurrentUserId() )

– getCurrentUserId() is not USER – It’s the application user; USER is always EmpDB

© Ellis Cohen 2002 - 2005 101

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 102

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 103

Multiple Application Domains

Tables

EmpDBEmpApp

HRApp

Does Own UserAuthentication

Does Own UserAuthentication

© Ellis Cohen 2002 - 2005 104

Mandatory Access ControlMechanisms

(MAC)Also Called Lattice-Based

Access Control (LBAC)

© Ellis Cohen 2002 - 2005 105

Trojan Horse ProblemTrojan Horse

Executable code that has undesirable side effects unknown to the user of the code

SupposeSCOTT 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

HoweverSCOTT creates a StolenInfo table

and grants INSERT on StolenInfo to PUBLICThe DataMine procedure copies all info from the

tables mined into StolenInfo

Stealing Top Secret InformationIf SCOTT has no clearance, and DataMine is used by

someone to mine top secret data potentially serious security breach

© Ellis Cohen 2002 - 2005 106

Mandatory Access ControlPurpose

Limit information flow via access controlPrevent 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 107

Questions about MACSuppose, 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 108

Row-Level Security andCovert Information Flow

equipid equipname count class

0736 Jeep 32 C

0877NuclearMissile

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

BaseEquipment

What are some possible solutions?

© Ellis Cohen 2002 - 2005 109

Row-Level Security Solution

• Always include tuples for secret & classified data, even if the count is 0

• Change the primary key toequipid + 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 110

Statistical Database Access

© Ellis Cohen 2002 - 2005 111

Privacy &Statistical Database Access

SupposeA 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 112

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 113

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 114

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 115

Inferring Private Information

Call the result of this query k1 and a1SELECT count(*), avg(yrsInPrison)

WHERE state = "MA"

Call the result of this query k2 and a2SELECT 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 querywe should NOT have been allowed to do!

How can we prevent this problem?

© Ellis Cohen 2002 - 2005 116

Approaches & Dangers

•Limit aggregate queries to ones which operate on a minumum number of rowsUse multiple queries whose overlap is a single row

•Use an inferencing engine to determine what a set of queries can inferExtremely hard problem

Suppose different users collaborate

•Randomly alter underlying data for each queryCan make it difficult to make accurate inferences

Has only a minor effect on true statistical queries