CSCI 5707: Database Security

CSCI 5707: Database SecurityCSCI 5707: Database Security

Pusheng Zhang

University of Minnesota

Email: [email protected]

March 2, 2004

21.2CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang

MotivationMotivation Personal Privacy

Q? Have you watched “LOR: The Return of The King”?

Q? Do you like the movie?

Customer profile DB, health information DB, credit rating DB

Corporate Security Trade Secrets – Coke’s Formula

Client Privacy – Swiss Banks, Financial Inst.

System Resource Security Password DB, Worm, Virus, and Hackers

Cyber Security Eavesdropping (unauthorized reading of messages)

Masquerading (pretending to be an authorized user or sending messages supposed from authorized users)


Database SecurityDatabase Security

This figure is courtesy of Peter J. Braam, CMU



Database SecurityDatabase Security Goal:

Users only see the data they’re supposed to. (S and A)

Guard against modifications by malicious users (I)

What security mechanisms do software systems provide? User Account Level Access Control

Discretionary: grant/revoke

Mandatory: security levels

Audit Trails: logs

Statistical Database Security: Inference Control

Data Object Level Access Control: encryption


Database AdministratorDatabase Administrator Database Administrator (DBA)

Central authority for managing a database system

Responsibilities include: Create user account and password

Grant privileges

Revoke privileges

Assign security levels



GRANT CommandGRANT Command GRANT Command

In SQL: GRANT privileges ON objects TO users [WITH GRANT OPTION]

Privileges: SELECT: can read all columns

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

DELECT: can delete tuples

UPDATE (col-name): can update this column

REFERENCE (col-name): can define foreign keys (in other tables) that refer to this column.

WITH GRANT OPTION can pass privilege on to other users


Example of GRANTExample of GRANT Joe created tables Sailors, Boats, Reserves

Q: Joe runs the following Q1: GRANT SELECT ON Reserves TO Mike

Mike can execute SELECT queries on Reserves

Q2: GRANT SELECT ON Sailors TO Mike WITH GRANT OPTION

Mike can execute SELECT queries on Sailors

Mike can pass this privilege to others for Sailors NOT for Reserves

Q3: GRANT UPDATE (rating) ON Sailors TO Bill

Bill can update the rating column in the Sailors.


REVOKE CommandREVOKE Command REVOKE Command

In SQL: REVOKE [GRANT OPTION FOR] privileges ON objects FROM user {RESTRICT | CASCADE}

Privileges are the same with GRANT

GRANT OPTION FOR: revoke just the grant option on a privilege For example: Joe is the creator of the Sailors. Joe runs the following

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION

REVOKE GRANT OPTION FOR SELECT ON Sailors FROM Art CASCADE

Art still holds SELECT privilege on Sailors

However, Art no longer can’t pass it on to other users


REVOKE Command (cont)REVOKE Command (cont) CASCADE and RESTRICT

CASCADE: recursively revokes existing privileges

RESTRICT: revoking is rejected if resulting in other privileges becoming abandoned For example: Joe is the creator of the Sailors

GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (by Joe)

GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (by Art)

REVOKE SELECT ON Sailors FROM Art CASCADE (by Joe)

Art and Bob lost SELECT privilege on Sailors

What happens if we use RESTRICT instead of CASCADE in the example above?


ExamplesExamples Example 1:


GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (by Art)

GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (by Joe)


Art lost the SELECT on Sailors

What about Bob?

Example 2: GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (by Joe)



Does Art lose the SELECT on Sailors or not?


Authorization GraphAuthorization Graph Authorization Graph

Nodes: Users

Arcs: Indications of how privileges are passes

Joe

Art Bob

(Joe, Art, Select on Sailors, Yes)

(Art, Bob, Select on Sailors, Yes)



Example of ViewExample of View For example: Joe runs

CREAT VIEW ActiveSailors (name, age, day)

AS SELECT S.sname, S.sage, R.day

FROM Sailor S, Reserves R

WHERE S.sid = R.sid AND S.rating > 6

Joe can grant SELECT on the view ActiveSailors to Art GRANT SELECT ON ActiveSailors TO Art WITH GRANT OPTION

Art only has the access to the ActiveSailors, not the base tables

Art can run:

– SELECT name FROM ActiveSailors WHERE age < 30


RoleRole Roles are named groups of related privileges

Can be assigned to users and even to other roles Reduced privilege administration Dynamic privilege management

Privileges can be granted to or revoked from roles, just like user

SQL:1999 standard supports roles CREATE ROLE Role-name DROP ROLE Role-name GRANT privileges ON objects TO Role-name


Example of RoleExample of Role Example

CREATE ROLE manager

GRANT SELECT, INSERT ON Sailors TO manager

GRANT UPDATE (sid) ON Sailors TO manager

GRANT SELECT, UPDATE, INSERT ON Reserves TO manager

GRANT manager TO Joe


Mandatory Access ControlMandatory Access Control Main drawback of discretionary access control (DAC):

Vulnerable to malicious attacks, e.g., Trojan horses whereby a devious unauthorized user can trick an authorized user into disclosing sensitive data.

DAC doesn’t impose any control on how info is propagated.

Supported by most commercial DBMSs.

Mandatory access control (MAC): Multilevel security:

Top secret, secret, confidential, and unclassified

Needed for government, military, and intelligence applications







PolyinstantiationPolyinstantiation Solution to the dilemma

Add one tuple with security class C: 101 Salsa Red S

101 Pasta Blue C

102 Pinto Brown C

Polyinstantiation: The presence of data objects that appear to have different

values to users with different clearances. E.g., the boat with bid 101


Comparison Between DAC and MACComparison Between DAC and MAC

Discretionary access control (DAC): Flexible

Supported by most commercial DBMSs

Applicable to a large variety of domains

Vulnerable to Trojan Horses

Mandatory access control (DAC): Very Rigid

Not supported in most Commercial DBMSs

Only applicable in military, intelligence, and government

Prevent flow from higher to lower security level

Documents

CSCI 5707: Database Security