Database Security
DB Security subsystem
• Authentication - ensures that a user is who
he or she claims to be.
• Authorization - allows the user access to
various resources based on the user's
identity (a.k.a. permission, access right,
privilege)
• Privacy - DBMS should provide
confidentiality
Database Security
• Different aspects of database security
– data encryption
– allow retrieval of statistical information
– Access control for a whole DBMS
• account numbers and passwords
– Access control for portions of a database
• DB security and authorization subsystems secure
portions of a DB against unauthorized access (4
approaches)
– Discretionary Access Control (DAC)
– Mandatory Access Control (MAC)
– Role Based Access Control (RBAC)
– Attribute Based Access Control (ABAC)
Discretionary Access Control
DAC – from the beginning of time ...
Discretionary Access Control
• Based on granting and revoking privileges
• 2 levels for assigning privileges
– account level (subject)
• independent of the relations
• create schema, create table, create view
– relation level (object)
on a particular base relation or view
Access (authorization) matrix
model
•
•
•
•
row - subject
column - object
M(i,j) -> read, write, update
for example M(a,B) = read means that subject a
holds read privilege on object B
• Owner of the relation (typically the creator) is
assigned the owner account for that relation and
is given all privileges on that relation
Grant/Revoke SQL statement
• Grant {privileges} on {table | view} to {user | public | role}
Grant select, delete on Employee, Department
to Smith
• Revoke {privilege} on {table | view} from {user | public |
role}
Revoke delete on Department from Smith
Using Views for Security
• Create view EMP as select Fname,
Lname, address from Employee where
dno=5;
Grant select on EMP to all;
Mandatory Access Control
MAC
Proposed in Mid 1980’s
Mandatory Access Control
•
Users have security clearances, data has security
classifications
• Need to restrict the access according to security level of
user and data
• Useful for environments with hierarchical propagation of
information
• Each subject and object are classified into one of the
security classifications
• Security classes example:
– TS(Top Secret), S (Secret), C(Classified), U
(Unclassified)
TS > S > C > U
Evolution of MLS models
• One way to utilize classification levels:
– multilevel relation (MLS) schema
– We will look at different MLS models to see
problems with each model and how these
were addressed by the next model
Security Levels
• Properties: First must decide who can see
which security level(s)?
Bell-LaPadulla properties
• All MLS Models are based on this
• Restrictions on data access –
– simple property: No READ UP
– star (*) property: No WRITE DOWN (write at
own level)
• Necessary but not sufficient conditions
• Still have problems – for example, covert
channel
Designing MLS models
• How would you include different security
levels in the data itself?
– Add a classification level to PK?
– Add a classification level to every attribute?
• Let us assume we have added a level for each
column
MLS Relation Example
Vessel(PK)
Micra U
Vision U
Avenger C
Logos S
Objective Destination
Shipping U Moon U
Spying U
Saturn U
Spying C
Mars C
Shipping S Venus S
Who sees what?
Vessel(PK)
Micra U
Vision U
Avenger C
Logos S
Objective Destination
Shipping U Moon U
Spying U
Saturn U
Spying C
Mars C
Shipping S Venus S
MLS Insert
• What if a U user wants to insert a tuple
with vessel = Avenger?
• 2 solutions:
1. reject the insert, but?
• Covert channel
Covert Chanel
• Indirect downward flow of information
– must be avoided since it allows downward
flow of information
– Can occur if reject update
– Can be used maliciously (higher level user
can signal lower level user)
MLS Insert
• What if a U user wants to insert a tuple
with vessel = Avenger?
2. Insert another Avenger
• Will have 2 avengers – problems?
• 2 tuples with the same PK - Violates
uniqueness of relational model
MLS Relation
Vessel
Micra U
Vision U
Avenger U
Avenger C
Logos S
Objective Destination
Shipping U Moon U
Spying U
Saturn U
Shipping U Mars U
Spying C
Mars C
Shipping S Venus S
MLS Insert
• What does it mean to have 2 tuples with
the same PK?
– Does this mean there are 2 different Avengers
– Or 1 Avenger with different info at different
classification levels?
MLS Update
• What if the S level wants to update one of the
tuples at the U level? (Vision)
Update Vision so Destination is Venus
• U should not see the update
• Solutions
–Replicate the tuple – polyinstantiation
1. Put a null for the value at the U level?
2. Keep the old value at the U level?
Solution 1.
Vessel
Micra U
Vision U
Avenger U
Avenger C
Vision U
Logos S
Objective Destination
Shipping U Moon U
Spying U Null U
Shipping U Moon U
Spying C
Mars C
Spying U
Venus S
Shipping S Venus S
Solution 2.
Vessel
Micra U
Vision U
Avenger U
Avenger C
Vision U
Logos S
Objective Destination
Shipping U Moon U
Spying U Saturn U
Shipping U Moon U
Spying C
Mars C
Spying U
Venus S
Shipping S Venus S
MLS - Jajodia-Sandhu Model (JS)
• Jajodia-Sandhu was one of the first MLS
models
• multilevel relation (MLS) schema
– For each attribute, classification attribute C
– Added a tuple classification TC
• Lowest user level that can see tuple
R(A1, C1, A2, C2, ...An, Cn, TC)
JS Relation Example
Vessel(PK)
Micra U
Vision U
Avenger C
Logos S
Objective Destination TC
Shipping U Moon U
U
Spying U
Saturn U
U
Spying C
Mars C
C
Shipping S Venus S
S
JS Insert
• What if a U user wants to insert a tuple
with vessel = Avenger?
Insert another Avenger
JS Insert
Vessel
Micra U
Vision U
Avenger U
Avenger C
Logos S
Objective Destination TC
Shipping U Moon U
U
Spying U
Saturn U
U
Shipping U Mars U
U
Spying C
Mars C
C
Shipping S Venus S
S
JS Insert
• JS model did not answer the question
below:
– Does this mean there are two different
Avengers or one Avenger with different info at
different classification levels?
JS Update
• What if the S level wants to update
Enterprise destination to Rigel?
JS Update
Vessel
Enterprise U
Objective
Exploration U
Destination TC
Talos U
U
S-user updates Enterprise destination to Rigel
Vessel
Objective
Destination TC
Enterprise U Exploration U
null U
U
Enterprise U Exploration U
Rigel S
S
What is view to U-user? S-user?
What does the null mean? Problem!
Covert channel?
JS Update
• U user wants to set Destination = Talos
where Starship = ‘Enterprise”
JS Update
Vessel
Enterprise U
Enterprise U
Objective
Exploration U
Exploration U
Destination TC
null U
Rigel S
U
S
U user wants to set Destination = Talos where Starship = ‘Enterprise”
U view:
Vessel
Enterprise U
Objective
Exploration U
Destination TC
Talos U
U
S View:
Vessel
Enterprise U
Enterprise U
Objective
Exploration U
Exploration U
Destination TC
Talos U
U
Rigel S
S
JS Update
• Suppose S users want to update
objective=spying where starship =
‘Enterprise” and destination =Rigel
JS Update
U view:
Vessel
Enterprise U
Objective
Exploration U
Destination TC
Talos U
U
S View:
Vessel
Enterprise U
Enterprise U
Objective
Exploration U
Exploration U
Destination TC
Talos U
U
Rigel S
S
Suppose S users want to update objective=spying where starship = ‘Enterprise”
and destination =‘Rigel’
S View:
Vessel
Enterprise U
Enterprise U
Objective
Exploration U
Spying S
Destination
Talos U
Rigel S
TC
U
S
JS Update
• Suppose U users want to update
objective=spying where starship =
‘Enterprise”
– There are 2 Enterprise tuples – both of which
have objective =Exploration at the U level
– Should it only update the tuple with TC=U?
JS Update
U view:
Vessel
Enterprise U
Objective
Exploration U
Destination TC
Talos U
U
S View:
Vessel
Enterprise U
Enterprise U
Objective
Exploration U
Exploration U
Destination TC
Talos U
U
Rigel S
S
U users want to update objective=Spying where starship = ‘Enterprise”
S View:
Vessel
Enterprise U
Enterprise U
Objective
Spying U
Exploration U
Destination
Talos U
Rigel S
TC
U
S
JS Update
•
•
•
•
•
Should the other Spying U be updated as well?
Should the Exploration change from U to S?
Not addressed in their early work
What does this mean?
Confusing?
Jajodia Sandhu MLS Model
• Entity integrity
– What is the primary key?
• PK is now called the Apparent Key
• CAK is the classification of the PK
AK, CAK, Ci -> Ai
– Implies Primary key in MLS is:
• AK U CAK U CR
• AK are data in PK, CAK is class of PK data, CR is
data not in AK
JS model Integrity Constraints
•
Entity integrity rule
– all attributes that are members of the apparent key must not be
null and must have the same security classification within each
individual tuple
• Null integrity
– Nulls are classified at the level of the key
– One tuple does not subsume another (null values subsumed by
non-null values)
• Inter-Instance Integrity
– User can only see portion of relation for which is cleared (use
filters)
– Data not cleared is set to null
– Eliminate subsumed tuples
Examples of Polyinstantiation
Integrity – JS model
Legal instance:
Vessel
Objective
Enterprise U Exploration U
Voyager U
Exploration U
Voyager U
Spying S
Destination TC
Talos U
U
Talos U
U
Mars S
S
Illegal instance: Why?
Vessel
Objective
Voyager U
Exploration S
Voyager U
Spying S
Destination TC
Talos S
S
Mars S
S
JS Insert
Suppose S wants to insert (Enterprise, Spying, Rigel) into:
Vessel
Enterprise U
Objective
Exploration U
Destination TC
Talos U
U
Objective
Exploration U
Spying S
Destination TC
Talos U
U
Rigel S
S
After Insert
Vessel
Enterprise U
Enterprise S
Are these different or the same? Problem!
JS Insert
• But what does it all mean to have tuples at
different classification levels?
• In the Jajodia Sandhu early model, this
was not made clear
Winslett Smith Belief Model
• Addressed some of these problems
– Tuples at user’s level believe info
– See info at lower levels
– Simplified: only 2 classification level columns
• KC and TC
R(K, KC, A1, A2, ... An, TC)
• PK is K, KC and TC
– Important: Every tuple has a base tuple –
level at which first inserted
Winslett Smith Belief Model
Can distinguish between different beliefs
Vessel
Enterprise U
Enterprise S
Objective
Exploration
Spying
Destination TC
Talos
U
Rigel
S
U believes and sees:
Enterprise U
Exploration
Talos
U
S sees U’s tuples, but believes the following:
Enterprise S
Spying
Rigel
S
Winslett Smith Belief Model
Can distinguish between different entities, and the
same entities
• Different entities (different CAK):
Vessel
Objective
Destination TC
Enterprise U Exploration
Talos
U
Enterprise S Spying
Rigel
S
• The same entities (same CAK):
Vessel
Objective
Destination TC
Enterprise U Exploration
Talos
U
Enterprise U Spying
Rigel
S
MLR Model Sandhu Chen
• Relational operations still messy in
Winslett/Smith
– What about joins – if at different levels?
• Try to eliminate semantic ambiguity
• Borrowing to indicate belief in lower level
tuples
– Does it mean T or F?
– Cannot indicate disbelief
Extensions to MLS model
• Belief consistent model (Jukic-Vrbsky)
– Can easily see what others believe at lower
levels
– Can assert if one level believes lower level
belief is false
– Reduces tuple propagation
– Useful for: e-Business and Customer
Relationship Modeling (CRM).
Belief consistent model
• Labels are positive or negative, positive means believes
the value is true, negative means a false belief
Vessel
Enterprise US
Enterprise US
Objective
Exploration US
Exploration U
Destination
Talos U-S
Rigel S
TC
U-S
S
• Enterprise US means one Enterprise
• -S means destination Talos is not believed by the S level
• If a classification level is not listed, it means it has no
belief
S has no belief in the Exploration U
• Too many labels for each column – confusing!
MLS Model
• MLS models never really became popular
• Why??
• However, in Oracle
– Oracle Label Security in 10g
• Sensitivity labels and security clearances
Role Based Access Control
RBAC
Mid 1990’s-now
Motivation
• Many organizations:
– Base access control in role of individual users
– Want to centrally control and maintain access
rights
– Access control needs are unique
• commercially available products lack flexibility
Motivation
• Roles define individuals and extent of resource access
• Combination of users and permissions can change
– E.g. user membership in roles
• Permissions associated with roles stable
• Administration of roles rather than permissions
• Role permission predefined
– Easier to add/remove users membership than create new
roles/permissions
• Roles part of SQL3
• Supported by many software products
– Roles used in Windows NT, XP (system admin)
Roles
• Role-based access control (RBAC)
• Sandhu, R., Coyne, Feinstein, Youman: “Role-Based Access
Control Models”
– Semantic construct
– System administrator creates roles according to job
functions
• Role
– Specific task competency, duty assignments
– Embody authority and responsibility
• Grant permissions to roles and users
– Permissions & Roles, Roles & Users
Role hierarchies
• More powerful roles at top, less powerful
on bottom
• Inherits up
– Inheritance transitive
– Multiple inheritance
– Partial order - reflexive, transitive,
antisymmetric
– Can create private roles not inherited
Constraints
• Mutually exclusive roles
– User at most 1 role in ME set
– Combinations of roles and permissions can be
prohibited
• Cardinality
– Maximum number of members in a role
– Minimum cardinality difficult to implement
• Prerequisite role
– User assigned to role B, only if assigned to A
– Permission p assigned to role only if role has
permission q
In Oracle
• Rather than grant privileges to individual
users, can grant them to groups using
roles
Create role role_name [identified by pw]
Grant {privilege} [on {table}] to role_name
Grant role_name to user
The user must enable the role if a pw is
specified with the command:
Set role role_name identified by pw
DAC, MAC vs. RBAC
• DAC vs. MAC emerged from defense
security research
• RBAC independent of access control
• RBAC can be used to implement DAC,
MAC
Attribute Based Access
Control
ABAC
Mid 2000’s
Why ABAC? – Web sharing
•
•
•
•
No longer have stove-piped info systems
Instead: collaboration and info sharing
Must balance accessibility with protection
Currently
– Firewall, intrusion detection (HTTP) – can have
potential attacks not detectable
– Need set of known users – may not be feasible
– Simple, static, coarse grained (roles) – doesn’t take
into account current threat level, community of
interest
ABAC
• Attribute Based Access Control
– Motivation – web based services technologies
and service oriented architectures
• Dynamic and adhoc
– Based on subject, object and environment
attributes
• Supports MAC and DAC needs
– Slides based on: “Attribute Based Access Control ABAC for
Web Services,” E. Yuan, J. Tong, ICWS’05.
ABAC
• Access granted based on attributes of user not
rights of subject associated with user
• User must prove claims about his attributes
Standards
• Industry Standards
– Security Assertions Markup Language (SAML)
– Authentication/authorization represented as XML assertions
– XML Access Control Markup Language (XACML) defined
architecture and policy language for access control
– Web Services Security (WSS) foundation for Simple Object
Access Protocol (SOAP)
• Security tokens, XML digital signature, XML encryption
• Standards focused on defining wire format not service-level
semantics, different parties interface with each other, need end-toend security
Definition of ABAC
•
•
ABAC
– Policy model – defines ABAC policies
– Architecture model – applies policies
Attributes
– Subject – entity (user, application, process) that acts on a resource
• Attributes: subject’s ID, name, organization, job title
– Resource – entity acted upon by subject
• Title, subject, date, author, ownership (extracted from metadata)
– Environment – operational, technical, situational
• Current date/time, virus/hacker activities, network security
level
– Not associated with a particular subject or resource
• Evaluation of policy rules – first order logic, forward chaining
Attributes
• ATTR(s)  SA1 X SA2 X … X SAk
• ATTR(r)  RA1 X RA2 X … X RAk
• ATTR(s)  EA1 X EA2 X … X Eak
– Subjects have a Role, User ID and can be Customer with an
address and credit rating or a Manager with a store and ssn)
– Resources have Owners and have names such as Previous
purchases, NewPurchase, ApprovePurchase)
• Assign attributes to s, r, e
– Role(s) = “Service Consumer”
– ServiceOwner(r) = “XYZ, Inc.”
– CurrentDate(e) = “01-23-2005”
Rules
• Rule : can_access (s, r, e) ← f(ATTR(s), ATTR(r), ATTR(e))
• Policy rules
– Rule1: can_access(s, r, e) ← (Role(s)=‘Manager’) ^
(Name(r)=‘ApprovePurchase’) // RBAC
– Rule2: can_access(s, r, e) ← (UserID(s) = ResourceOwner(r))
// resource can only be accessed by owner
ABAC vs RBAC:
• Example
RBAC
– 3 roles: adult, juvenile, child
– 3 permissions: can view R-rated movies, PG13 movies, G-rated movies
– Adult all 3 permissions, juvenile 2, child 1
Example
ABAC
• Age is s attribute, rating r attribute
• Eliminates definition/management of static
roles
Expand example
• Suppose expand to include new, old release
Changes to RBAC
Changes to ABAC
Authorization
Architecture
•
•
•
•
Attribute Authorities AA
– creating, managing attributes for s, r, e
– Binding attributes to entity of interest
Policy Enforcement Point PEP
– requesting and enforcing authorization
decisions
– Point of presence for access control, cannot be bypassed
Policy Decision Point PDP
– Evaluating policies and making authorization decisions
– When policy references s, r, or e, contacts AA to retrieve attribute
values
Policy Authority PA
– Create/manages access control policies
Securing Web Services
Implementation
• JAX-RPC message handlers to intercept SOAP
request messages
• Policy decision services implemented using
Apache Axis
• Policy stored and retrieved in XACML
Advantages of ABAC
• Intuitive to model
• More flexible and powerful
• Management of security can be distributed over
network (AA, PA)
• ABAC can be used to implement DAC, MAC,
RBAC