1 advanced database topics copyright © ellis cohen 2002-2005 access control mechanisms these slides...
TRANSCRIPT
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