Download Database Security

CSCI 5707: Database Security
Pusheng Zhang
University of Minnesota
Email: [email protected]
March 2, 2004
Motivation
 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)
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.2
Database Security
This figure is courtesy of Peter J. Braam, CMU
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.3
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.4
Database 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.5
Database 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.6
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.7
GRANT 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.8
Example 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.
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.9
REVOKE 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.10
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?
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.11
Examples
 Example 1:
 GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (by Joe)
 GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (by Art)
 GRANT SELECT ON Sailors TO Bob WITH GRANT OPTION (by Joe)
 REVOKE SELECT ON Sailors FROM Art CASCADE (by Joe)
 Art lost the SELECT on Sailors
 What about Bob?
 Example 2:
 GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (by Joe)
 GRANT SELECT ON Sailors TO Art WITH GRANT OPTION (by Joe)
 REVOKE SELECT ON Sailors FROM Art CASCADE (by Joe)
 Does Art lose the SELECT on Sailors or not?
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.12
Authorization Graph
 Authorization Graph
 Nodes: Users
 Arcs: Indications of how privileges are passes
Joe
(Joe, Art, Select on Sailors, Yes)
Art
Bob
(Art, Bob, Select on Sailors, Yes)
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.13
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.14
Example 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.15
Role
 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.16
Example 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.17
Mandatory 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

CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.18
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.19
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.20
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.21
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.22
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.23
Polyinstantiation
 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
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.24
Comparison Between DAC and MAC
 Discretionary access
 Mandatory access control
control (DAC):
(DAC):
 Flexible
 Very Rigid
 Supported by most
commercial DBMSs
 Not supported in most
Commercial DBMSs
 Applicable to a large
variety of domains
 Only applicable in military,
intelligence, and government
 Vulnerable to Trojan
Horses
 Prevent flow from higher to
lower security level
CSCI 5707, Spring 2004. University of Minnesota, Pusheng Zhang
21.25