Chapter 6 - Database Security

04/20/23Prof. Ehud Gudes Security

Ch 6 1

Chapter 6 - Database Security

Stallings Chp. 5


Ch 6 2

Levels of a Database System

END USER

EXTERNAL VIEW

EXTERNAL VIEW

…

CONCEPTUAL SCHEMA

INTERNAL SCHEMA

STORED DATABASE

EXTERNAL LEVEL

External / conceptual mapping

CONCEPTUALLEVEL

Conceptual / internal mapping

INTERNALLEVEL


Ch 6 3

A Typical Architecture of a DBMS

A typical DBMS Architecture


Ch 6 5

Introduction to DB Security

Secrecy: Users should not be able to see things they are not supposed to.

e.g., a student cannot see other student’s grades.

Integrity: Users should not be able to modify things they are not supposed to.

e.g., only instructors can assign grades.

Also, the DBMS should protect the database from non-malicious integrity errors, i.e Concurrency & Recovery issues

Availability: users should be able to see and modify things they are allowed to.


Ch 6 6

Integrity Problems in Databases

Checks on values – single record checks, before and after update checks, etc.

Various integrity constraints – primary keys, unique checks, foreign keys, etc.

General integrity constraints – Constraints, Asserts, Triggers.

Consistency problems as a result of concurrent execution of transactions – CC protocols such as Two-Phase Locking

Integrity problems as results of system failure – Log and Recovery

Prof. Ehud Gudes Security Ch 6

Security - Policies and Mechanism - Reminder

Policies – general guidelines on authorization in the system, examples:

Students can see their gradesOnly instructors can change grades

Mechanisms – techniques to enforce the policies

Access controlEncryption


Categories of Security Policies - Reminder

Mandatory vs. Discretionary (Need to Know).Ownership vs. AdministrationCentralized vs. DistributedClose vs. OpenName, Content or Context dependent Individual, Group or Role based Information Flow Control based


DAC - The Access Matrix Model

Subjects - users, groups, applications, transactionsObjects - Files, programs, databases, relations, URLs Access-types - Read, write, create, copy, delete, execute, killAuthorization commands - enter, remove, transferAuthorizers - Owners, users, administrators


Ch 6 10

The Access Matrix Model

OBJECTS

SUBJECTS

SubjectsFilesDevices

S1S2F1F2D1D2

S1CallReadWrite

Seek

S2SendReadRewind

S3KillDelete

Compatibility Lists

Access Lists


Ch 6 11

Objective of the model: trying to keep secrets and avoid illegal flow

Both subjects and objects are assigned security levels:Public, Confidential, Secret, Top Secretdominance relationship between security levels: ‚ ‘

• Simple Security Property: Successful read access: Clearance (S) Class (O)

• *-Property: Successful write access: Class (O) Clearance (S)

Mandatory Policy - Bell and LaPadula Model


DBMS Security Policies

Usually DAC, sometimes Mandatory (BLP)Ownership, Usually (SQL) DistributedCloseName, Content dependent (using Views) Individual, or Role based Inference control policies

Note, assumes security at lower layers, i.e: OS, Hardware and User authentication

Database Access Control

DBMS provide access control for databaseassume have authenticated userDBMS provides specific access rights to

portions of the databasee.g. create, insert, delete, update, read, writeto entire database, tables, selected rows or

columnspossibly dependent on contents of a table entry

can support a range of policies:centralized administrationownership-based administrationdecentralized administration


Ch 6 14

DBMS Discretionary Access Control

Based on the concepts of access rights or privileges for objects (tables and view), and mechanisms for giving users privileges (and revoking privileges).

Creator of a table or a view automatically gets all privileges on it.DBMS keeps track of who subsequently gains and

loses privileges, and ensures that only requests from users who have the necessary privileges (at the time the request is issued) are allowed.


Ch 6 15

History of Relational Systems

Codd’s paper – early 70sTwo research systems: Berkeley Ingres and IBM

System R – late 70sSQL was developed based on System RAll relational systems today are SQL (92,99)

compatibleSecurity:

Ingres – DAC, centralized, Rule-basedSystem R – DAC, Distributed, View based

SQL security follows System R security


Ch 6 16

Security in INGRES

Centralized, DBA enters authorization rulesThe query predicate is combined with the relevant

rule predicates to derive a modified queryThe concept of query modification – partial results

are possibleDifficult to manage a large group of users and rules

.


Ch 6 17

Protection in IngresDBA

User

PROTECTION INTERACTIONS

CONVERT TO

INTERNAL FORM

CONVERT TO

INTERNAL FORM

QUEL

query

VALIDATE AND

MODIFY

PROTECTIONSHARED

RELATIONS


Ch 6 18

(Rule 1) range of E is employeepermit E to Jones forretrieve (E.name, E.mgr)

where E.dept = ‘D1’

(Rule 2) range of E is employeepermit E to Jones forretrieve (E.name, E.dept, E.mgr)

where E.dept = ‘D1’

(Rule 3) permit E to jones for retrieve (E.name, E.sal)where E.mgr = ‘jones’

(Rule 4) permit E to jones for retrieve (E.sal)where E.sal < 100000

Protection in Ingres, cont.


Ch 6 19

Query1 range of E is employeeretrieve (E.name, E.Sal)

Only Rule3 matches, query is modified to; range of E is employee

retrieve (E.name, E.Sal) where (E.mgr = ‘Jones’)

Query2 range of E is employeeretrieve (E.name)

Both Rules1,2 and 3 match (see Hovereth)

Protection in Ingres, cont.


Ch 6 20

+Query simplicity Multiple table-queries may be expressed simply against a view

+ Structural simplicity Views can give a user a 'personalized' interpretation of the database

Security – a user sees only the portion relevant to him

+ Performance Views may be precompiled and

optimized

Update restrictions Many views are 'read-only'

The concept of Views – A Window over the database


Ch 6 21

The example database scenario

Employee Project

ssn

name

dep

salary

subject

title

client

date

ssn title

function

N M

Assignment

1 N

manages

Example Database (1)


Ch 6 22

AssignmentSSN Title

123 Celsius

124 Alpha

124 Beta

125 Alpha

125 Beta

125 Celsius

126 Celsius

Employee SSN Name Department Salary

123 Bob Sales 4.0 K

124 Susan Research 4,9 K

125 Josef Data Proc. 3,9 K

126 Calvin Assembling 6,2 K

127 Josef Research 6,2 K

Title Subject Client Manager

Alpha Development A 124

Beta Research B 125

Celsius Production C 123

Project

Example Database (2)

23

CREATE VIEW view-name AS query

(-- column_name --)

,

SSN Name Department

123 Bob Sales

124 Susan Research

125 Josef Data Proc.

126 Calvin Assembling

127 Josef Research

Horizontal View

(1) CREATE VIEW earning_little AS SELECT * FROM Employee WHERE Salary 5K

Vertical View

(2) CREATE VIEW emp AS SELECT SSN, Name, Department FROM Employee

SSN Name Department Salary 123 Bob Sales 4.0 K 124 Susan Research 4.9 K 125 Josef Data Proc. 3.9 K

earning_little

emp

Horizontal / Vertical View


Ch 6 24

(3) CREATE VIEW emp_research AS

SELECT SSN, Name, Department FROM Employee

WHERE Department = ‚Research‘

(4) CREATE VIEW dep_involved AS SELECT Title, Subject, Department

FROM Project, Assignment, Employee

WHERE Employee.SSN = Assignment.SSN AND

Assignment.Title = Project.Title

dep_involved

Title Subject Department Alpha Development Research Alpha Development Data Proc. Beta Research Research Beta Research Data Proc.

Celsius Production Assembling Celsius Production Data Proc. Celsius Production Sales

emp_research

SSN Name Department 124 Susan Research 127 Josef Research

Mixed View (1)


Ch 6 25

(5) CREATE VIEW dep_avg_salary AS

SELECT Department, Avg (Salary)

FROM Employee

GROUP BY Department

(6) CREATE VIEW my_employees AS

SELECT SSN, Name, Department, Salary

FROM Project, Assignment, Employee

WHERE Employee.SSN = Assignment.SSN AND

Assignment.Title = Project.Title AND

Manager = USER

for User ‚123‘

SSN Name Department Salary 126 Calvin Assembling 6,2 K 125 Josef Data Proc. 6,2 K 123 Bob Sales 4,0 K

dep_avg_salary

Department Avg

(Salary) Sales 4,0 K

Research 5,6 K Data Proc. 3,9 K

Assembling 6,2 K

Mixed View (2)


Ch 6 26

Views are ideal for security...

Views are ideal for security…value independent controls )2(

value dependent controls )1) ,(3) ,(4(

statistical controls )5(

context dependent controls )6(


Ch 6 27

The View Update problem

How to translate update on a view to unambiguous update on the Base tables?

Examples:Add an employee with salary >5K into view 1Add an employee to View 2 (null values)Update Salary in View 5.Add a new row into View 4

Generally the solution is: allow updates only on single level views which

include the primary key and all non-null attributes


Ch 6 28

Views and Security

Enable convenient specification and enforcement of access to portions of the database, which include any horizontal, vertical or join on the Base tables using standard SQL

Once a view is defined, the access to it is binary, either yes or no

Access control is provided only if access is via the view

Distributed administration: users are owners of the views they define and can delegate access further

Views are problematic for update


Ch 6 29

Authorization in SQL based systems – The GRANT command

The following privileges can be specified: SELECT: Can read all columns (including those added later

via ALTER TABLE command). INSERT(col-name): Can insert tuples with non-null or non-

default values in this column.INSERT means same right with respect to all columns.

DELETE: Can delete tuples. REFERENCES (col-name): Can define foreign keys (in other

tables) that refer to this column. If a user has a privilege with the GRANT OPTION, can pass

privilege on to other users (with or without passing on the GRANT OPTION).

Only owner can execute CREATE, ALTER, and DROP.

GRANT privileges ON object TO users [WITH GRANT OPTION]


Ch 6 30

GRANT SELECT

INSERT

DELETE

UPDATE

(column-name )

,,

ALL PRIVILEGES

ON base relation

view relation

TO user-name

PUBLIC

WITHGRANTOPTION

GRANT-Statement


Ch 6 31

REVOKE SELECT

INSERT

DELETE UPDATE

( column-name

)

,

, ALL PRIVILEGES

ON table-name FROM

GRANT OPTION FOR

user-name view-name PUBLIC

RESTRICT CASCADE

,

REVOKE Statement


Ch 6 32

ANSI / ISO SQL Standard SELECT

INSERT

DELETE

UPDATE

GRANT

DB2, Oracle ALTER

CREATE INDEX

Sybase, Sql Server EXTENDED SELECT

EXECUTE

DB2 USE Tablespace

Access Privileges in different DBMSs


Ch 6 33

GRANT and REVOKE of Privileges

GRANT INSERT, SELECT ON Employees TO Horatio Horatio can query Employees or insert tuples

into it.

GRANT DELETE ON Employees TO Yuppy WITH GRANT OPTION Yuppy can delete tuples, and also authorize

others to do so.

GRANT UPDATE Salary ON Employees TO Dustin Dustin can update (only) the salary field of

Employees tuples.


Ch 6 34

Revoke options

Reject (SQL)

Non-recursive revocation (Fernandez)

Time based recursive revocation (System R)

System based recursive revocation (SQL)


Ch 6 35

Protection in System R

.A:GRANT READ ON EMP TO B WITH GRANT OPTIONA:GRANT READ ON EMP TO C WITH GRANT OPTIONB:GRANT READ ON EMP TO XC:GRANT READ ON EMP TO X

Protection in System R

ולכן שלילת הזכויות C ומ-B קיבל זכויות משני גורמים מ-Xבדוגמה זו רואים כי . אם לדוגמה נבצע את הפקודהX אינה גורמת בהכרח שלילת הזכויות מ-Bמ-

A: REVOKE READ ON EMP FROM Bנקבל את הגרף באיור ( SYSTEM Rאזי במקרה של קיום שלילה רקורסיבית (

-א' )FERNANDEZובמקרה של אי קיום שלילה רקורסיבית (לפי

נקבל את הגרף באיור - ב'.


Ch 6 37

a1(_SYSTEM, A, SELECT, T, yes, 10)

a2(A, B, SELECT, T, yes, 20) a3(A, C, SELECT, T, yes, 30)

a4(B, D, SELECT, T, yes, 40)

a5(D, E, SELECT, T, yes, 50)

a6(C, D, SELECT, T, yes, 60)

a7(D, F, SELECT, T, yes, 70)

a8(E, G, SELECT, T, yes, 80)

A

B

2

3

D

C

E

F

G4

5

6 7

8

The privilege dependency graph


Ch 6 38

A

B

2

3

D

C

E

F

G4

5

6 7

8

B

A

2

3

D

C F

6 7

REVOKE IN SYSTEM R

Revoking a4 (with CASCADE option) will succeed. Authorization a7will not be revoked, because it is supported by a6, but a5 and a8

Will be revoked. The privilege dependency graph will change.


Ch 6 39

REVOKE in System RREVOKE: procedure (grantee, privilege, table, grantor);

comment turn off the grantee’s authorization for privilege obtained from granter;set privilege = 0 in the (grantee, table, grantor) tuple in SYSAUTH;comment find the minimum timestamp for the grantee’s remaining grantable privilege on table;m current timestamp;for each granter u such that (grantee, privilege, table, u, grantable) is in

SYSAUTH do if privilege 0 and privilege < m then m privilege;

comment revoke grantee’s grants of privilege on table which were made before time m;

For each user u such that (u, privilege, table, grantee) is in SYSAUTH do if privilege < m

then REVOKE (u, privilege, table, grantee) ;returnend REVOKE


Ch 6 40

Suppose that at time t=35, B issues the command REVOKE ALL RIGHTS ON EMPLOYEE FROM X. Clearly the (X, EMPLOYEE, B) tuple must be deleted from SYSAUTH. In order to determine which of X’s grants of EMPLOYEE must be revoked, we form a list of X’s remaining incoming grants:

Protection in System R, cont.

As well as a list of X’s grants to others:

The grant of the DELETE privilege by X to Y at time t=25 must be revoked because his earliest remaining DELETE privilege was received at time t=30. But X’s grants of READ and INSERT are allowed to remain because they are still “supported” by incoming grants which occurred earlier in time.

USERIDTABLEGRANTORREADINSERTDELETE

XEMPLOYEEA15150

XEMPLOYEEB20020

YEMPLOYEEX252525

XEMPLOYEEC30030

TABLEREADINSERTDELETE

EMPLOYEE{15, 30}{15}{30}


Ch 6 41

GRANT/REVOKE on Views

If the creator of a view loses the SELECT privilege on an underlying table, the view is dropped!

If the creator of a view loses a privilege held with the grant option on an underlying table, (s)he loses the privilege on the view as well; so do users who were granted that privilege on the view!


Ch 6 42

Revoking Access on Views- System R

REVOKE : procedure (grantee, table, grantor) ;delete the (grantee, table, grantor) tuple in

SYSAUTH;for each u such that (u, table, grantee) is in

SYSAUTH do REVOKE (u, table, grantee) ;for each view such that (table, view, grantee) is

in SYSUSAGE do DROP (view) ;return ;end REVOKE ;

DROP :procedure (view) ;delete the view definition from the system ;for each u1 and u2 such that (u1, view, u2) is in

SYSAUTH do REVOKE (u1, view, u2) ;for each v and u such that (view, v, u) is in

SYSUSAGE do DROP (v) ;return ;end DROP ;


Ch 6 43

REVOKE in SQL

RESTRICT – accept only if there are no privileges resulted SOLELY from the revoked command, otherwise reject

CASCADE – remove privileges recursively as in System R, but do not consider time!, that is, if a privilege was granted to B by A, and A’s rights were revoked, but LATER A was given these rights independently, then don’t revoke B’s rights - this is equivalent to saying that there is a path from the “System” node


Ch 6 44

Protection in SQLGRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Joe)GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (executed by Art)GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (executed by Bob)GRANT SELECT ON Sailors TO Cal WITH GRANT OPTION (executed by Joe)GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (executed by Cal)REVOKE SELECT ON Sailors FROM Art CASCADE (executed by Joe)


Ch 6 45

System

Joe

Cal

Art

Bob

(System, Joe, Select on Sailors, Yes)

Protection in SQL, cont.


Ch 6 46


What happens if Joe revokes access from Cal


Ch 6 47

a1(_SYSTEM, A, SELECT, T, yes, 10)

a2(A, B, SELECT, T, yes, 20) a3(A, C, SELECT, T, yes, 30)

a4(B, D, SELECT, T, yes, 40)

a5(D, E, SELECT, T, yes, 50)

a6(C, D, SELECT, T, yes, 60)

a7(D, F, SELECT, T, yes, 70)

a8(E, G, SELECT, T, yes, 80)

A

B

2

3

D

C

E

F

G4

5

6 7

8

The privilege dependency graph


Ch 6 48

A

B

2

3

D

C

E

F

G4

5

7

8

SQL - REVOKE with RESTRICT option

Revoke of a4 with RESTRICT option will fail! If we have added a6 ,then it would not have failed!


Ch 6 49

• Negative authorizations

• Non cascading revoke

A

B

2

3

D

C

E

F

G4

5

6 7

8A

B

2

3

D

C

E

F

G5

6 7

8

What may be useful and is not supported in SQL92?


Ch 6 50

Why needs SELECT right with Integrity constraints?

May infer values from non permitted table!

CREATE TABLE Sneaky (maxsalary INTEGER,CHECK ( maxsalary >=

( SELECT MAX (S.salary ) FROM Employees

S )))



Ch 6 51


Why SELECT right is not sufficient?Since owner rights may be restricted (cannot delete

rows)!Needs explicit REFERENCE right

CREATE TABLE Assignments (project CHAR (10) NOTNULL, SSN INTEGER,

day DATE, PRIMARY KEY (SSN, day),

FOREIGN KEY (SSN) REFERENCES Employees ON DELETE NO ACTION


Ch 6 52

Differences Between System R and SQL-92

New privileges – REFERENCE, USAGE

CASCADE or RESTRICT on Revoke

CASCADE different then System R – not time-stamp based

Precise definitions for Rights on viewsE.g. the impact of adding/removing a right to/from the base tables

Authorization-Ids (for programs), Groups and Roles

Role-Based Access Control

role-based access control work well for DBMSeases admin burden, improves security

categories of database users:application ownerend useradministrator

DB RBAC must manage roles and their userscf. RBAC on Microsoft’s SQL Server

Table 5.2 in [SB] lists a set of administrative roles for MS-SQL server


Ch 6 54

Role-Based Authorization

In SQL-92, privileges are actually assigned to authorization ids, which can denote a single user or a group of users.

In SQL:1999 (and in many current systems), privileges are assigned to roles. Roles can then be granted to users and to other

roles. Reflects how real organizations work. Illustrates how standards often catch up with “de

facto” standards embodied in popular systems.


Ch 6 55

Roles and PermissionsMedical_Staff: collectively, responsible for all aspects of direct

patient care.

Nurse: Direct involvement with patient care on a daily basis.

Physician: Handle the medical needs (diagnosis, treatment, etc.) for patients.

Pharmacists: Control the supply and distribution of all drugs throughout the hospital.

Technician: Provide a variety of medical testing support for Patients.

Therapist: Evaluate patients and develop treatment plans for therapy.

Staff_RN: Administer direct care to patients and implement the physician treatment plan.


Ch 6 56

Discharge_Plug: Link between patients and outside agencies for care after discharge.

Education: Educate both the nursing staff and patients regarding new treatment and self care.

Manager: Responsible for the day-to-day operation of a nursing unit

Director: (For Physician or Pharmacist) Responsible for the day-to-day operation of their respective

department/medical service.

Private: the physician within his/her office/private–practice setting.

Attending: A physician that hes privileges to admit and treat patients at a hospital.

Roles and Permissions, cont.


Ch 6 57

The User-Role Definition Hierarchy

User Types, User Classes and Selected User Roles

Medical StaffUsers

Nurse Physician Pharmacist Technician Therapist

Support Staff

Support

Prepare room Volunteer Security

Other

Patient Spouce


Ch 6 58

Role-Based Models

RBAC0 – Users, Roles, Permissions, Sessions

RBAC1 – RBAC0 + Role-hierarchies

RBAC2 – RBAC0 + Constraints

RBAC3 – RBAC0 + Role-hierarchies + Constraints


Ch 6

RBAC0

.המודל הבסיסי עליו מתבססים שאר המודלים

Users(U)

Roles(R)

Userassignment

(UA)

Permissionassignment

(PA) Permissions(P)

Sessions(S)


Ch 6

RBAC1

היררכייתRole.ים-

Users(U)

Roles(R)

Userassignment

(UA)


(PA) Permissions(P)

Sessions(S)

Role hierarchy(RH)


Ch 6

RBAC1

היררכיה שלRoleים-:.קשר אב ובן.הרשאות אפקטיביות וישירות

Employee[Read]

Developer[Read,Develop]

QA[Read,Test]

Admin[Read,Test,Develop]


Ch 6

RBAC1

הגבלת ירושה.

Employee[Read]

Developer[Read,Develop]

QA[Read,Test]

Admin[Read,Test,Develop]

Developer'[Read,Develop,Build]


Ch 6

RBAC2

מודל האילוציםRole.ים מנוגדים-

Users(U)

Roles(R)

Userassignment

(UA)


(PA) Permissions(P)

Sessions(S)

Constranits


Ch 6

RBAC3

המודל המשולב: אילוצים והיררכייתRoles .

Users(U)

Roles(R)

Userassignment

(UA)


(PA) Permissions(P)

Sessions(S)

Role hierarchy(RH)

Constranits


Ch 6 65

Constraints in RBAC – Separation of duties

Conflicts between Permissions – conflicting permissions cannot be in the same Role or in two roles with a common ancestor

Conflicts between Roles – the same user cannot be in two conflicting roles

Conflicting usersStatic constraints – max. number of roles per

user, permissions per role, etcDynamic constraints – session dependent


Ch 6 66

Roles in SQL99New in SQL99; benefits:

Simplifies definition of complex sets of privileges

Roles are created

CREATE ROLE AuditorCREATE ROLE AuditorGeneral

Roles may be assigned to users & rolesGRANT Auditor TO AuditorGeneralWITH ADMIN OPTIONGRANTED BY CURRENT ROLE

GRANT Auditor TO Smith

Controllable whether to grant as user or role


Ch 6 67

Roles in SQL99, cont.

Roles (like users) may own objects

As to users, privileges may be granted to roles Grant INSERT ON TABLE Budget TO AuditorThis privilege also among privileges of AuditorGeneral

A role R identifies a set of privileges:Those directly granted to RThose of the roles granted to R


Ch 6 68

At any time there is at least a valid current user or a valid current role.

Current user can be set

SET SESSION AUTHORIZATION ‘JDOE’Current role can be set or invalidates

SET ROLE AuditorOperations (e.g. INSERT) determine the kind of required

privilegesOften: union of user’s and role’s privileges

Session context maintains stack of user and role identifier pairsNew pair is pushed when externally invoked procedure is executedTemporarily makes client module identifier the current userEnables invoker’s rights in a limited fashion

Roles in SQL99, cont.


Ch 6 69

Advantages of RBACConvenient representation and mapping of the

organization structureConvenient distribution of the administration of

RolesEasier definition and understanding of the security

policy of the organizationRole-hierarchy and inheritance of permissions

eases administrator jobChanges in user roles are simple and controllableSessions allow the same user different roles in

different contextsGrouping multiple users to roles allow easier

control of their permissions


Ch 6 70

Security in Object-Oriented Databases

Composition hierarchy [K]Generalization hierarchy [K]Explicit and implicit authorization [K]Strong and weak authorization [K]Inheritance – which authorizations are inherited?

[G]Algorithm for evaluation [G]Negative authorization [G]


Ch 6 71

Database Granularity HierarchySystem [MCC]

database [Inventory] database [CAD] Database…

class [vehicle] class [automobile] class [4-wheel-vehicle] class [Motor-Vehicle]

instance [1] instance [2] Instance… instance [100]

Attribute-value [Weight] Attribute-value…

Database Granularity Hierarchy


Ch 6 72

Class Hierarchy

Vehicle

Automobile

4-Wheel-Vehicle Motor-Vehicle

IS-A

IS-A

IS-A

IS-A


Ch 6 73

Implicit Weak Authorization with Weak Exceptions


Ch 7 74

Implicit Weak Authorization with Strong Exceptions


Ch 6 75

Security in OO Databases


Ch 6 76

Mandatory Access Control

Based on system-wide policies that cannot be changed by individual users. Each DB object is assigned a security class. Each subject (user or user program) is assigned a

clearance for a security class. Rules based on security classes and clearances

govern who can read/write which objects.

Most commercial systems do not support mandatory access control. Versions of some DBMSs do support it; used for specialized (e.g., military) applications.


Ch 6 77

Why Mandatory Control?

Discretionary control has some flaws, e.g., the Trojan horse problem: Dick creates Horsie and gives INSERT privileges to

Justin (who doesn’t know about this). Dick modifes the code of an application program

used by Justin to additionally write some secret data to table Horsie.

Now, Dick can see the secret info.

The modification of the code is beyond the DBMSs control, but it can try and prevent the use of the database as a channel for secret information.


Ch 7 78

Bell-LaPadula Model

Objects (e.g., tables, views, tuples)

Subjects (e.g., users, user programs)

Security classes: Top secret (TS), secret (S), confidential (C),

unclassified (U): TS > S> C > U

Each object and subject is assigned a class. Subject S can read object O only if class(S) >=

class(O) (Simple Security Property) Subject S can write object O only if class(S) <=

class(O) (*-Property6


Ch 6 79

Intuition

Idea is to ensure that information can never flow from a higher to a lower security level.

E.g., If Dick has security class C, Justin has class S, and the secret table has class S: Dick’s table, Horsie, has Dick’s clearance, C. Justin’s application has his clearance, S. So, the program cannot write into table Horsie.

The mandatory access control rules are applied in addition to any discretionary controls that are in effect.


Ch 6 80

Multilevel Relations

Users with S and TS clearance will see both rows; a user with C will only see the 2nd row; a user with U will see no rows.

If user with C tries to insert <101,Pasta,Blue,C>: Allowing insertion violates key constraint Disallowing insertion tells user that there is another

object with key 101 that has a class > C! Problem resolved by treating class field as part of key.

CBrownPinto102

SRedSalsa101

classcolorbname

bid


Ch 6 81

Sea View(SRI International, Oracle, Gemsos)MLS relational datamodel, supports polinstentiation on db-, relation- , tupel- and attribute levels.

LDV (LOCK Data Views)(Honeywell SCTC, MITRE)Extended relational data model, polyinstatiation on tuple level. Supports application dependent and non application dependent integrity rules.

MLS-Prototype systems


Ch 6 82

A Database D;A relation R within the database D;The primary key for a tuple r within the relation R;

The attribute i, identifying the element ri within the tuple r.

To get through to the element ri, the following must hold:

lab(D)lab(R) lab(ri)

Otherwise, you could be barred access to an element you are entitled to see. In convention, a user who has access to an element of r must have access to its primary key.Therefore: lab(rk) lab(ri)

Jajodia - Formal Integrity Rules


Ch 6 83

Jajodia - Formal Integrity Rules, cont.

Rule Multi-level entity integrity: no component of a primary key of a base relation may be null. All components of a primary key of a base relation have the same access class. In a base relation, the access class of all other data values in a tuple dominates the access class of the primary key of that tuple.


Ch 6 84

Rule Multi-level reference integrity: a tuple referenced by a foreign key has to exist. The access class of the foreign key dominates the access class of the corresponding primary key.

Rule The access class of a view dominates the access classes of all relations used in the definition of the view.

Rule The access class of a tuple dominates the access classes of all attributes in the tuple.

Formal Integrity Rules, cont.


Ch 6 85

Multi-level Relation

Flight [Fl_Class]Dest.

[De_Class]Seats

[Se_Class][Tuple_Class]

CA909 [C]H.K. [C]7 [C][C]

AX301 [U]K.L. [U]2 [U][U]

GR555 [U]L.A. [C]11 [C][C]

Figure 15.1 The Relation Bookings with Primary Key Flight


Ch 6 86

Multi-level Relation – view of C user


[De_Class]Seats

[Se_Class]

CA909 [C]H.K. [C]7 [C]

AX301 [U]K.L. [U]2 [U]

GR555 [U]L.A. [C]11 [C]

Figure 15.1 The Relation Bookings with Primary Key Flight


Ch 6 87

Multi-level relation – view of U user

Figure 15.2 List of Non-Confidential Data from fig. 15.1 Accessible to Unclassified User

FlightDestSeats

AX301K.L.2

GR555----


Ch 6 88

if the DBMS should not inform a lower trusted user that tries to insert data that the data is already in the system,

if a higher trusted user wishes to change lower classified data, to avoid (covert) signalling channels,

if the understanding of the reality is different among users with differing security labels (i. e., cover stories should be supported).

Polyinstatiation is necessary


Ch 6 89

Why Poly-instantiation?A low user tries to add information on flight CA909.

If refused – inference, if accepted - violation of primary key constraint

A low user tries to update information on flight GR555.If refused – inference, if accepted - violation of

functional dependencyA high user attempt to change destination of flight

AX301 If refused – restricts access, if accepted - violation

of functional dependencySolution: accept and include tuple class as part of the

primary key!.


Ch 6 90

Polyinstatiated table after User U update


[De_Class]Seats


CA909 [C]H.K. [C]7 [C][C]

AX301 [U]K.L. [U]2 [U][U]

GR555 [U]L.A. [C]11 [C][C]

GR555 [U]N.Y. [U]0 [U][U]

Figure 15.4 Updated Version of Table Data Given in Figure 15.1.


Ch 6 91

Polyinstatiation Cont.

FlightDestSeats

CA909H.K.7

AX301K.L.2

GR555L.A.11

GR555N.Y.0

Figure 15.5 Data Accessible to Confidential User


Ch 6 92

Subsumption

If user view has a null in U attribute and User C update it with non-null value, the C tuple subsumes the U tuple and only one tuple is visible to C


Ch 6 93

Polyinstantiation integrity

Polyinstantiation integrity If two tuples in a base relation have the same primary key and the respective entries for some attribute have the same access class, then also the data values for this attribute are the same. If two tuples of a base relation have the same primary key and if there are some attributes where the respective entries have different access classes, then the values for those attributes may differ and any combination of these values (and access classes) gives again a tuple in the relation.


Ch 6 94

Polyinstantiation Integrity


[De_Class]Seats


CA909 [C]H.K. [C]7 [C][C]

AX301 [U]K.L. [U]2 [U][U]

GR555 [U]L.A. [C]11 [C][C]

GR555 [U]L.A. [C]0 [U][C]

GR555 [U]N.Y. [U]11 [C][C]

GR555 [U]N.Y. [U]0 [U][U]

Assume query: Dest = NY and Seats = 11 by C user – need to add two rows over table from p. 105


Ch 6 95

Implementation Options

1. Rely only on ML-OS There is a separate single-level DBMS process running

at each access class. Multi-level relations are stored as a collection of single- level operating systems. The DBMS has to use a partial ordering of access classes supported by the operating system.

2. DBMS is a Trusted Subject Proceed with the update and polyinstantiate the data, or Deny the update and record this event in an audit log.


Ch 6 96

MLS Concurrecy Control

Assume user S locked a record for write and now user U tries to read it. The existence of this lock is already secret information!

If lock is at level S, user U (or U scheduler) should be unaware of it and will try to read the record.

If lock is at level U then user S violated BLP!

SOLUTION? Read papers!

Inference

Inference Example


Ch 6 99

Statistical DB Security

Statistical DB: Contains information about individuals, but allows only aggregate queries (e.g., average age, rather than Joe’s age).

New problem: It may be possible to infer some secret information! E.g., If I know Joe is the oldest sailor, I can ask

“How many sailors are older than X?” for different values of X until I get the answer 1; this allows me to infer Joe’s age.

Idea: Insist that each query must involve at least N rows, for some N. Will this work? (No!)


Ch 6 100

Why Minimum N is Not Enough

By asking “How many sailors older than X?” until the system rejects the query, can identify a set of N sailors, including Joe, that are older than X; let X=55 at this point.

Next, ask “What is the sum of ages of sailors older than X?” Let result be S1.

Next, ask “What is sum of ages of sailors other than Joe who are older than X, plus my age?” Let result be S2.

S1-S2 is Joe’s age!


Ch 6 101

Types of Sensitive Data

Exact data – e.g. salary of John Doe

Bounds

Negative results – e.g. 0 is not the total number of felonies

Existence – e.g. of AIDS virus

Probable values


Ch 6 102

Example Database

NAME(Not

stored)

SEXLEV(job level)

LOC(Work location)

SAL(Salary)

0.10.20.3

DIAZM60SF36122

SMITHF58SF24321

JONESM56LA26423

KATZM57LA30332

CLARKF58LA28514

WONDF60LA34111

WEBBM58SF32555

103

Stat. DB security – size restriction

הגנה אפשרית מפני שתי שאילתות אלו היא הגבלה כי גודל !1התשובה לכל שאילתא יהיה גדול מ-

אולם אז ניתן לשאול את השאילתות הבאות:

Q1=COUNT(LOC=‘SF’LOC=‘SF’)

Q2=COUNT(LOC =‘SF’SEX=‘F’)

– מס' הרשומות בטבלה.7התשובה לשאילתא הראשונה תהיה Q1-Q2=1 וההפרש ביניהן אחד 6התשובה לשאילתא השנייה תהיה

מכאן ניתן לבצע את שתי השאילתות הבאות:

Q3=SUM(LOC=‘SF’LOC=‘SF’;SAL)

Q4=SUM(LOC=‘SF’SEX=‘F’;SAL)

!Q4-Q3והמשכורת הרצויה היא כמובן


Ch 6 104

Stat. DB security – size restriction רואים טבלה ובה מידע על עובדים ומשכורותיהם (שים לב 7.5בטבלה

ששדה השם אינו מופיע בבסיס הנתונים). אחד הדברים שאיננו מעונינים לחשוף הוא משכורתו של עובד מסוים. אולם קל מאוד כן

לחשוף זאת ע"י שאילתא חוקית לחלוטין (ע"י תהליך הסקה). שאילתא חוקית היא מהצורה:

function (Predicate; Attribute) הוא Attribute, ו-SUM או COUNT היא פונקציה כמו functionכאשר

השדה שעליו פועלת הפונקציה. גרה בעיר Smithלדוגמא, נניח שאנו יודעים כי הפרט שאנו מעונינים בו

SF.(סן פרנסיסקו)והיא אשה אזי ביצוע השאילתות הבאות

COUNT (LOC=‘SF’ . SEX=‘F’) SUM (LOC=‘SF’ . SEX=‘F’;SAL)וכן

!Smithייתן את משכורתה של


Ch 6 105

The individual Tracker

Assume C characterize the individual uniquely – then Q(C) or Q(C*S) is unanswerable, S is the searched field.

Assume C=AB where both Q(A) and Q(AB^) are answerable.

Then Q(C)=Q(A)-Q(AB^) orQ(C*S)=Q(A*S)-Q(AB^*S)


Ch 6 106

The Individual Tracker - Example

C=F*CS*Prof, A=F, B=CS*Prof

Unique Identifier

SexDeptPositionSalary ($K)Political Contribution ($)

AdamsMCSProf.2050

BakerMMathProf.15100

CookFMathProf.25200

DoddFCSProf.1550

EngelMStatProf.180

FlynnFStatProf.22150

GradyMCSAdm.1020

HayesMMathProf.18500

IronsFCSStu.310

JonesMStatAdm.2015

KnappFMathProf.25100

LordMCSStu.30


Ch 6 107

The General Tracker

Assume threshold is K.Find T such that

2k <= count(T) <= n-2k

Then, k <= count(T+C) <= n-k andk <= count(T^+C) <= n-k

So, both are answerable!And Q(C) = Q(T+C) + Q(T^+C) –n !


Ch 6 108

Some Defenses

Replacing precise values with range values

Use samples from the original database

Perturb data randomly

Perturb results randomly

Partition the database

Audit trail and query analysis

Protecting Against Inference

Other Query Restrictions

query set overlap control limit overlap between new & previous querieshas problems and overheads

partitioningcluster records into exclusive groupsonly allow queries on entire groups

query denial and information leakagedenials can leak information to counter must track queries from user

Perturbation

add noise to statistics generated from datawill result in differences in statistics

data perturbation techniquesdata swappinggenerate statistics from probability distribution

output perturbation techniquesrandom-sample querystatistic adjustment

must minimize loss of accuracy in results


Ch 6 112

The Inference Problem, cont.

To show that a refusal to answer may reveal a secret, we now consider a system that only refuses if the answer would reveal a secret. Suppose the following integrity constraints apply to a database containing the fact that Mediocrates is an Athenian:

Every man is an Athenian, a Boeotian, a Corinthian, or a Dorian;

All Athenians and Corinthians are peaceable;All Boeotians and Dorians are violent;


Ch 6 113

The Inference Problem, cont.

Mediocrates does not wish it to be known that he is peaceable. Rhinologus, a public nuisance, tries to find out about Mediocrates:

Rhinologus: Is Mediocrates an Athenian?System: I will not tell you.Rhinologus: Is he a Boeotian?System: No.Rhinologus: Is he a Corinthian?System: No.Rhinologus: Is he a Dorian, then?System: I will not tell you.


Ch 6 114

The Inference Problem – Answering Queries Without Revealing Secrets

k

k

k

k

“is Mediocrates an Athenian”?

“is Mediocrates a Boeotian”?

“is Mediocrates a Corinthian”?

“is Mediocrates a Dorian”?

k

mum

mum

mum

mum

yes

yes

yes

yes

no

no

no

no

K ‘M is peaceable’


Ch 6 115

Database Encryption

116

DBMS Data - The Attackers

Intruder Tries to attack the confidentiality or integrity

of the database. Tries to take over the identity of a regular user (or

DBA). Most attacks are targeted at web applications.

The database service provider \ Administrator Tries to obtain information beyond his

own access rights. Tries to change the content of the database for his

own benefit (e.g., change account balance). Most attacks are targeted at outsourced databases.

The data owner \ Client Has sufficient privileges to tamper with the access

right definition – possibly unlimited privileges.

Database Encryption

databases typical a valuable info resourceprotected by multiple layers of security:

firewalls, authentication, O/S access control systems, DB access control systems, and database encryption

can encryptentire database - very inflexible and inefficientindividual fields - simple but inflexible records (rows) or columns (attributes) - best

also need attribute indexes to help data retrieval

varying trade-offs

Database Encryption


Ch 6 119

Database Encryption at the Table Level

Encrypting the entire table after every change.

Substitution and statistical attacks on the table values are eliminated.

Weakness: In order to execute a query the whole table needs to be decrypted.

Client DBMS Encrypted Database

Encryption

DecryptionSecured

Communication

Intruder

Insider

Admin

#$*#@#$%^#$@!@#$%%$@!@#&$&^*%$%^&$


Ch 6 120

Database Encryption at the Cell Level

Encrypting each cell separately.Only the data of interest needs to be

decrypted while performing a query.

Weakness: Substitution and statistical attacks are possible.


Encryption

DecryptionSecured

Communication

Intruder

Insider

Admin

RowVal

0%$

1!@

2%$

%$16


Ch 6 121

Database Encryption at the Row Level

The database encryption scheme described by Davida(81) is based on the Chinese-Reminder theorem.

Each row is encrypted using different sub-keys for different cells. Enables: encryption at the level of rows and decryption at the

level of cells.

Weakness: Requires re-encrypting the entire row when a cell value is modified.

Weakness: The basic element in the database is a row and not a cell, thus the structure of the database needs to be changed.


Ch 6 122

SPDE - A New Database Encryption Scheme

Each cell is encrypted with its uniquecell coordinates.

Only the data of interest needs to bedecrypted while performing a query.

Substitution and statistical attacksare eliminated.


Encryption

DecryptionSecured

Communication

Intruder

Insider

Admin

RowVal

0&$

1@#

2*^

&$16


Ch 7 123

Cell Coordinates Characteristics

Stable cell coordinates: Insert, update and delete operations do not change

the coordinates of existing cells. For example, this is the case in the Oracle

database.

If a database reorganization process changes cell coordinates, all affected cells are to be re-encrypted with their new coordinates.


Ch 7 124

IndexingEncrypted Data


Ch 6 125

Building an Index on the Encrypted Data

Indexing the encrypted data using a hash index.Equality queries are possible.

Weakness: Statistical attacks are possible by usingthe index.

Weakness: No range queries.

Row-idVal

AAA&$

AAB@#

AAC&$

@#

&$

Encrypted Table Index

Row-idVal

AAA16

AAB26

AAC16

Decrypted Table


Ch 6 126

Encrypting Each Index Value Separately

Building the index on the plaintext values and encrypting each index value separately.

Range queries are possible.

Weakness: Statistical attacks are possible by using the index. Weakness: The order of the ciphertext values is exposed.

Row-idVal

AAA&$

AAB@#

AAC&$


&$

&$

Maximum@#

Row-idVal

AAA16

AAB26

AAC16

Decrypted Table


Ch 6 127

Encrypting Each Index Node Separately

The indexing scheme provided by Damiani(03) suggests encrypting each node of the B+-Tree as a whole.

References between the B+-Tree nodes are encrypted together with the index values.

The index does not reveal the statistics or order of the database values

Weakness: The index structure is concealed.

Row-idVal

AAA#!

AAB^&

AAC*#

Encrypted Table

Index

@#

Row-idVal

AAA16

AAB26

AAC16

Decrypted Table

*!

&$


Ch 6 128

A New Database Indexing Scheme

Each index value is the result of encrypting a plaintext value in the database with its row-id.

This ensures that the index does not reveal the statistics or order of the database values.

The new database indexing scheme preserves the index structure.

Row-idVal

AAA#!

AAB^&

AAC*#


@#

&$*!

Row-idVal

AAA16

AAB26

AAC16

Decrypted Table


Ch 6 129

SPDE - Conclusions

A new structure preserving scheme for database encryption has been presented.

In the new scheme, patterns matching and substitution attacks cannot succeed, thus guaranteeing information confidentiality and data integrity.

The new schemes do not impose any changes on the database structure. A DBA is able to manage the encrypted database as

any other non-encrypted database. Implementing the new scheme in existing applications

does not entail modifying the queries.

SQL Injection

Traditional DB

• Two-tier architecture• Users are fixed and known• Users’ number is limited• All transactions are passed via the same

connection and users connect directly to the DB

Traditional DB Access Control

• DB can identify and authenticate its users

• DB can authorize users by traditional user/role-based access control

• It is quite easy to follow up single user transactions to seek signs of intrusion

• Views can be used to determine for a user the only part of the database that interests her

Web Databases

•Three-tier architecture

•Users are casual and unknown

•Users’ number is not limited

•Users do not connect directly to the DB

Connection Pooling

Different web users can run their SQL statements on the same DB connection and one user can run her SQL statements on different connectionsThis technique contributes to application

efficiency since the time to open and close the connection is saved per each request

It has serious implications on the database’s access control mechanism

Web DB Access Control

Web DB does not identify the real application user who accesses it

The only user accessing the database is the user of the web application server – most often with full access privileges (administrator or “super-user”)

No user-based access control can be appliedOnly limited RBAC can be appliedThe principle of minimal privilege is violatedNo more fine-grained access control to the

web DB exists

Web DB is vulnerableThere is no way to limit the web user privileges

at the database level of the web databases.There are still many secured web applications,

but their security can be achieved only by application means (writing lines of code that implement security policies) and not by database access control means (GRANT/REVOKE and VIEWS)

This situation is very problematic: Implementing access control by writing code is a time

consuming task Enterprise may have one DB but many applications,

then access control is distributed and in many cases not consistent

Programmers must be security specialists

As a result: "70% of websites are at immediate risk of being hacked!" (http://www.acunetix.com)

Attack example: SQL Injection

strSQL= "SELECT Salary FROM Salary_Table WHERE Employee_No = 123 AND Salary_Date = '" + dateParam + "'"

SELECT Salary FROM Salary_Table WHERE Employee_No = 123 AND Salary_Date = '01/2007' OR '1' = '1'

• In many Web application the SQL sentence is structured as a string and the user’s parameter is concatenated to this string:

• But the intruder can type `01.2007' or '1' = '1` and retrieve the entire table:

SQL Injection

SQL uses single and double quotes to switch between data and code.Semi-colons separate SQL statementsExample query:

"UPDATE users SET prefcolor='red' WHERE uid='joe';"

This command could be sent from a web front-end to a database engine. The database engine then interprets the command

Dynamic SQL Generation

Web applications dynamically generate the necessary database commands by manipulating strings Example query generation:

$q = "UPDATE users SET prefcolor='$INPUT[color]' WHERE uid='$auth_user'";

Where the value of "$INPUT[color]" would be originating from the client web browser, through the web server. And where the value for "$auth_user" would have been stored on the server and verified through some authentication scheme

Client Web Browser

Forms in client browsers return values to the web server through either the POST or GET methods

"GET" results in a url with a "?" before the values of the form variables are specified:

http://www.example.com/script?color=redThe value of "$INPUT[color]" is set to "red" in the

script

"GET" urls are convenient to hack, but there isn't any significant difference in the security of either "GET" or "POST" methods because the data comes from the client web browser regardless and is under the control of the remote attacker

The SQL Table

Tables are used to store information in fields (columns) in relation to a key (e.g., "uid")What other fields could be of interest?CREATE TABLE users ( prefcolor varchar(20), uid VARCHAR(20) NOT NULL, privilege ENUM('normal', 'administrator'), PRIMARY KEY (uid));

A Malicious SQL Query

What if we could make the web server generate a query like:

"UPDATE users SET prefcolor='red', privilege='administrator'

WHERE uid='joe';"

Can we engineer the value of "color" given to the web server so it generates this query?

Note how code and data are mixed in the same channel

Better database interfaces provide separate channels

Malicious HTTP Request

http://www.example.com/script?color=red',privilege='administratorThe "color" input is then substituted to generate SQL:


It gives the query we wanted!

Results

Joe now has administrator privileges.

Adding Another SQL Query

Let's say Joe wants to run a completely different query:

"DELETE * FROM users"This will delete all entries in the table!

How can the value of "color" be engineered?

Malicious HTTP Request

http://www.example.com/script?color=red'%3Bdelete+from+users%3B

%3B is the url encoding for ";"

What happens when the "color" input is used to generate SQL?


Result

UPDATE users SET prefcolor='red';delete from users;WHERE uid='$auth_user'";The last line generates an error, but it's already too late; all entries have been deleted.The middle query could have been anything

FAQs

Couldn't the database have a separate account for "Joe" with only the privileges he needs (e.g., no delete privilege)?

In theory yes, but in practice the management of such accounts and privileges, and connecting to the database with the correct IDs, adds significant complexity

Most often a database account is created for the entire web application, with appropriate limitations (e.g., without privileges to create and drop tables)A good compromise is to create database accounts for

each class of user or class of operation, so:• if Joe is a regular user he wouldn't have delete privileges for the user table•Changing user preferences, as an operation type, doesn't require delete privileges

FAQs

Doesn't SSL protect against this sort of attack?No

But what if you authenticate users with a username/password over SSL? Then, if the user does SQL injection, the server admins will know who perpetrated the crime, right?

Not necessarily; only if you have sufficient auditlogging.

What to do?

Careful writing of Web applications including strong input validation

More reliance on Database security including the use of Views and Roles

Our method of Prevention and Detection using Parameterized Views


Ch 6 150

Summary

Three main security objectives: secrecy, integrity, availability.

DB admin is responsible for overall security. Designs security policy, maintains an audit trail,

or history of users’ accesses to DB.

Two main approaches to DBMS security: discretionary and mandatory access control. Discretionary control based on notion of

privileges. Mandatory control based on notion of security

classes.

Statistical DBs try to protect individual data by supporting only aggregate queries, but often, individual information can be inferred.

Chapter 6 - Database Security

Documents

ehud gudes security

security levels

security policies

simple security property

successful read access

successful write access

urls accesstypes

typical dbms architecture