Operating Systems

1
Chapter 7
2
Levels of a Database System
END USER
EXTERNAL LEVEL
EXTERNAL VIEW

EXTERNAL VIEW
External / conceptual mapping
CONCEPTUALLEVEL
CONCEPTUAL SCHEMA
Conceptual / internal mapping
INTERNAL SCHEMA
INTERNALLEVEL
STORED DATABASE
3
A Typical Architecture of a DBMS
4
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 students
  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
• Availability users should be able to see and
  modify things they are allowed to.

5
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.
• Integrity problems as results of system failure
  Log and Recovery

6
Security - Policies and Mechanism

• Policies general guidelines on authorization in
  the system, examples
• Students can see their grades
• Only instructors can change grades
• Mechanisms techniques to enforce the policies
• Access control
• Encryption

7
Categories of Security Policies

• Mandatory vs. Discretionary (Need to Know).
• Ownership vs. Administration
• Centralized vs. Distributed
• Close vs. Open
• Name, Content or Context dependent
• Individual, Group or Role based
• Information Flow Control based

8
DAC - The Access Matrix Model

• Subjects
• - users, groups, applications, transactions
• Objects
• - Files, programs, databases, relations, URLs
• Access-types
• - Read, write, create, copy, delete, execute,
  kill
• Authorization commands
• - enter, remove, transfer
• Authorizers
• - Owners, users, administrators

9
The Access Matrix Model
Compatibility Lists Access Lists
10
Access Control Lists

• The access matrix is too large and too sparse to
  be practical
• It can be stored by columns
• Objects have ordered lists of domains that can
  access them
• Access bits RWX express access to files by users
  and groups
• Prohibiting access specifically, by owner, can be
  expressed as
• File1 (Amnon,staff,RWX)
• File2 (,student,R--), (Rachel,,---)
• File3 (Mike,,R-X)

11
The Information Flow Problem of DAC (II)
12
Mandatory Policy - Bell and LaPadula Model
Objective of the model trying to keep secrets
and avoid illegal flow Both subjects and objects
are assigned security levels Public,
Confidential, Secret, Top Secret dominance
relationship between security levels ?
Simple Security Property Successful read
access Clearance (S) ? Class (O)
-Property Successful write access Class
(O) ? Clearance (S)
13
Bell and LaPadula Model (2)
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.

15
History of Relational Systems

• Codds paper early 70s
• Two research systems Berkeley Ingres and IBM
  System R late 70s
• SQL was developed based on System R
• All relational systems today are SQL (92,99)
  compatible
• Security
• Ingres DAC, centralized, Rule-based
• System R DAC, Distributed, View based
• SQL security follows System R security
• .

16
Security in INGRES

• Centralized, DBA enters authorization rules
• The query predicate is combined with the relevant
  rule predicates to derive a modified query
• The concept of query modification partial
  results are possible
• Difficult to manage a large group of users and
  rules
• .

17
Protection in Ingres
DBA
PROTECTION INTERACTIONS
User
SHARED RELATIONS
PROTECTION
18
Protection in Ingres, cont.

• (Rule 1) range of E is employee permit E to
  Jones for retrieve (E.name, E.mgr) where
  E.dept D1
• (Rule 2) range of E is employee permit E to
  Jones for retrieve (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 3) permit E to jones for retrieve
  (E.sal) where E.sal lt 100000

19
The concept of Views A Window over the database
20
Example Database (1)
manages
1
N
date
function
ssn
title
name
N
M
Employee
Project
subject
dep
Assignment
client
salary
ssn
title
21
Example Database (2)
Project
22
Horizontal / Vertical View
CREATE VIEW view-name
AS query
(-- column_name --)
,
earning_little
emp
23
Mixed View (1)
24
Mixed View (2)
25
Views are ideal for security...




26
The View Update problem

• How to translate update on a view to unambiguous
  update on the Base tables?
• Examples
• Add an employee with salary gt5K into view 1
• Add 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

27
Views and Security

• Views can be used to present necessary
  information (or a summary), while hiding details
  in underlying relation(s).
• Given ActiveSailors, but not Sailors or Reserves,
  we can find sailors who have a reservation, but
  not the bids of boats that have been reserved.
• Creator of view has a privilege on the view if
  (s)he has the privilege on all underlying
  tables.
• Together with GRANT/REVOKE commands, views are a
  very powerful access control tool.

28
Summary 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

29
Authorization in SQL based systems The GRANT
command
GRANT privileges ON object TO users WITH GRANT
OPTION

• 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.

30
GRANT-Statement
31
REVOKE in SQL92
32
Access Privileges and the principle of delegation
of rights
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.

34
Protection in System R
. A GRANT READ ON EMP TO B WITH GRANT
OPTION A GRANT READ ON EMP TO C WITH GRANT
OPTION B GRANT READ ON EMP TO X C GRANT READ ON
EMP TO X

35
Protection in System R

?????? ?? ????? ?? X ???? ?????? ???? ??????
?-B ??-C ???? ????? ??????? ?-B ???? ????? ?????
????? ??????? ?-X. ?? ?????? ???? ??
?????? A REVOKE READ ON EMP FROM B ??? ????? ??
???? ????? ????????? ???? ?? ???? ????? 7.6?'
?????? ?? ?? ???? ????? ????????? ???? ?? ????
????? 7.6?'.
36
The privilege dependency graph
37
REVOKE IN SYSTEM R
Revoking a4 (with CASCADE option) will succeed.
Authorization a7
will not be revoked, because it is supported by
a6, but a5 and a8
Will be revoked. The privilege dependency graph
will change.
38
REVOKE in System R

• REVOKE procedure (grantee, privilege, table,
  grantor)
• comment turn off the grantees authorization for
  ?privilege? obtained from ?granter?set
  ?privilege? 0 in the (grantee, table, grantor)
  tuple in SYSAUTHcomment find the minimum
  timestamp for the grantees remaining grantable
  ?privilege? on ?table?
• m ? current timestampfor each granter u such
  that (grantee, privilege, table, u, grantable) is
  in SYSAUTH do if privilege ? 0 and privilege lt
  m then m ? privilege
• comment revoke grantees 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 lt m
  then REVOKE (u, privilege, table, grantee)
• return
• end REVOKE

39
Protection in System R, cont.

• Suppose that at time t35, 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 Xs
  grants of EMPLOYEE must be revoked, we form a
  list of Xs remaining incoming grants

As well as a list of Xs grants to others
The grant of the DELETE privilege by X to Y at
time t25 must be revoked because his earliest
remaining DELETE privilege was received at time
t30. But Xs grants of READ and INSERT are
allowed to remain because they are still
supported by incoming grants which occurred
earlier in time.
40
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!

41
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

42
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 As rights
  were revoked, but LATER A was given these rights
  independently, then dont revoke Bs rights -
  this is equivalent to saying that there is a path
  from the System node

43
Protection in SQL

• GRANT 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)

44
Protection in SQL, cont.
System
(System, Joe, Select on Sailors, Yes)
Joe
Art
Cal
Bob
45
Protection in SQL, cont.
What happens if Joe revokes access from Cal
46
The privilege dependency graph
47
SQL - REVOKE with RESTRICT option
B
4
2
D
E
G
8
5
A
3
7
F
C
Revoke of a4 with RESTRICT option will fail! If
we have added a6, then it would not have failed!
48
What may be useful and is not supported in SQL92?

• Negative authorizations
• Non cascading revoke

B
5
2
E
G
8
A
D
3
7
6
F
C
49
Protection in SQL, cont.

• Why needs SELECT right with Integrity
  constraints?
• May infer values from non permitted table!
• CREATE TABLE Sneaky (maxsalary INTEGER,
• CHECK ( maxsalary gt
• ( SELECT MAX (S.salary )
• FROM Employees S )))

50
Protection in SQL, cont.

• 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

51
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

52
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 SQL1999 (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.

53
Roles and Permissions

• Medical_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.

54
Roles and Permissions, cont.

• 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/privatepractice setting.
• Attending A physician that hes privileges to
  admit and treat patients at a hospital.

55
The User-Role Definition Hierarchy
User Types, User Classes and Selected User Roles
56
Role-Based Models

• RBAC0 Users, Roles, Permissions, Sessions
• RBAC1 RBAC0 Role-hierarchies
• RBAC2 RBAC0 Constraints
• RBAC3 RBAC0 Role-hierarchies Constraints

57
RBAC0

• ????? ?????? ???? ??????? ??? ???????.

58
RBAC1

• ???????? Role-??.

59
RBAC1

• ??????? ?? Role-??
• ??? ?? ???.
• ?????? ????????? ???????.

60
RBAC1

• ????? ?????.

61
RBAC2

• ???? ????????
• Role-?? ???????.

62
RBAC3

• ????? ??????
• ??????? ????????? Roles.

63
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 users
• Static constraints max. number of roles per
  user, permissions per role, etc
• Dynamic constraints session dependent

64
????? ??????????????

• ????? ??? Role ???? ?-Role ?????????????.
• ???? ????? ?-Role.
• ???? ????? ?-Role.
• ???? Role ?-Role.

65
???? ??????? ?-Role-??

• ????? Role ??????
• ????? ????? ?????? ?? Role ????????????? ?? ???
  ???? can_assign.
• ????? Role ??????
• ????? ????? ?????? ?? Role ????????????? ?? ???
  ???? can_revoke.
• ????? ???? Role ???? ???? ?????? ??????.
• ????? ???? ????? ?? ?? ??????.

66
????? ???????? Role-?? ???????????????
67
???? ?????? ?? ?????? ????????? Role-??
???????????????
68
???? ?????? ?? ?????? ????????? Role-??
???????????????

• ?????? ??? ?????? ??-Role ?????????????? 1PSO
  ??????, ?? ??????? ???? Role ??
  ??????E1,PE1,QE1 ??? ????? ???? ?- ED ROLE
• ??? ???? ???? ????? ????? Role ?? ??? ?? ???
  ????? ?????Role ??.????? ?????? ???? (range
  notation) ?? ??? ???? ????Role ??(x,y) r
  ? Rx ? r ? r gt y x,y r ? Rx ? r ? r ?
  y(x,y) r ? Rx gt r ? r gt y (x,y r ?
  Rx gt r ? r ? y

69
Roles in SQL99

• New in SQL99 benefits?Simplifies definition of
  complex sets of privileges
• Roles are createdCREATE ROLE AuditorCREATE
  ROLE AuditorGeneral
• Roles may be assigned to users rolesGRANT
  Auditor TO AuditorGeneralWITH ADMIN
  OPTIONGRANTED BY CURRENT ROLEGRANT Auditor TO
  Smith
• Controllable whether to grant as user or role

70
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 Auditor?This
  privilege also among privileges of
  AuditorGeneral
• A role R identifies a set of privileges?Those
  directly granted to R?Those of the roles granted
  to R

71
Roles in SQL99, cont.

• At any time there is at least a valid current
  user or a valid current role.
• Current user can be setSET SESSION
  AUTHORIZATION JDOE
• Current role can be set or invalidatesSET ROLE
  Auditor
• Operations (e.g. INSERT) determine the kind of
  required privileges?Often union of users and
  roles privileges
• Session context maintains stack of user and role
  identifier pairs?New pair is pushed when
  externally invoked procedure is
  executed?Temporarily makes client module
  identifier the current user?Enables invokers
  rights in a limited fashion

72
Advantages of RBAC

• Convenient representation and mapping of the
  organization structure
• Convenient distribution of the administration of
  Roles
• Easier definition and understanding of the
  security policy of the organization
• Role-hierarchy and inheritance of permissions
  eases administrator job
• Changes in user roles are simple and controllable
• Sessions allow the same user different roles in
  different contexts
• Grouping multiple users to roles allow easier
  control of their permissions

73
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

74
Database Granularity Hierarchy
Database Granularity Hierarchy
75
Class Hierarchy
76
Implicit Authorization
77
Implicit Weak Authorization with Weak Exceptions
78
Implicit Weak Authorization with Strong Exceptions
79
Security in OO Databases
80
A University Database

• IEEE TRANSACTIONS ON KNOWLEDGE AND DATA
  ENGINEERING, VOL. 6, NO. 2, APRIL 1994

Defined Attribute
G Generalization Association A Aggregation
Association
Object Class
81
Effective Structure of the University Database

• IEEE TRANSACTIONS ON KNOWLEDGE AND DATA
  ENGINEERING, VOL. 6, NO. 2, APRIL 1994

Person
A
G
Student
Teacher
A
A
G
Name
Foreign Student
SSN
SSN
Course
Name
A
SSN
Name
Visa
Year
G Generalization Association A Aggregation
Association
82
Example Policies

• For example, consider the graph of the second
  figure. Assume the following authorization rules
  are definedR1 (SA, Read, S.SSN) The Student
  Advisor can read SSN of students.R2 (FSA,
  Read, (FS.SSN, FS.Visa)) The Foreign Student
  Advisor can read SSN and visa of foreign
  students.

83
Example Policies, cont.

• A Student Advisor (SA) could have access to SSNs
  of all students (P1), but no access to their
  visas (P3) a Foreign Student Advisor (FSA) could
  have access to visas but only to SSNs of Foreign
  Students (P2).

84
Example Policies, cont.

• Q1 read SSN for all students
• Q2 read SSN and visa for all foreign students
• According to these policies, we expect the
  following behavior as a result of the evaluation
  of the indicated requests(SA, Q1) (SA, Read,
  S.SSN) All SSNs can be read (Policy P1)(SA,
  Q2) (SA, Read, FS.Visa, FS.SSN) Only SSNs
  of foreign students are to be read and not their
  visas (Policy P3)

85
Evaluating Security
Data Descriptions
Authorization Rules
Database
Evaluation Architecture
86
Query Graphs
Query Graphs for queries Q1 an Q2
Query Security Graphs for the Example
87
Evaluation Results

• Case 1 (SA, Q1) (SA, Read, S.SSN).
• The algorithm finds rule R1 and therefore gives
  SA acess to all SSNs.
• Case 2 (SA, Q2) (SA, Read, FS.SSN, FS.Visa).
• The algorithm first looks at node FS and cannot
  find any rules.then it looks at node S. Now it
  updates AT by removing attribute visa, since it
  is not known at this node and therefore no rule
  can reference it. Now it finds the rule (SA, R,
  S.SSN), and since obviously S includes FS it
  allows access to all SSNs for foreign students
  but not to their visas.

88
Evaluation Results, cont.

• Case 3 (FSA, Q1) (FSA, Read, S.SSN).
• The algorithm first looks at S and cannot find
  any rules. Then it looks at P and cannot find any
  rules. Now it goes downwards and finds R2. It
  updates AT_yes with FS.SSN and therefore allows
  access to SSNs of foreign students only.
• Case 4 (FSA, Q2) (FSA, Read, FS.SSN,
  FS.Visa).
• The algorithm looks at FS, finds rule R2 and
  allows access to both SSNs and visas.
• The above algorithm scans the entire security
  graph for each individual query node. Therefore ,
  its worst-case complexity is O(nmk).

89
OO Security Administration
Academic Institute
A
SSN
Department
Section
Person
A
A
G
Name
Student
Teacher
Enrollment
G
A
Foreign Student
Course
A
C1
A Security Context in the University database
90
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.

91
Why Mandatory Control?

• Discretionary control has some flaws, e.g., the
  Trojan horse problem
• Dick creates Horsie and gives INSERT privileges
  to Justin (who doesnt 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.

92
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 gt Sgt C gt U
• Each object and subject is assigned a class.
• Subject S can read object O only if class(S) gt
  class(O) (Simple Security Property)
• Subject S can write object O only if class(S) lt
  class(O) (-Property)

93
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
• Dicks table, Horsie, has Dicks clearance, C.
• Justins 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.

94
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 lt101,Pasta,Blue,Cgt
  
• Allowing insertion violates key constraint
• Disallowing insertion tells user that there is
  another object with key 101 that has a class gt C!
• Problem resolved by treating class field as part
  of key.

95
Jajodia / Sandhu Model (Sigmod91)
Jajodia / Sandhu Model (Sigmod91)
96
MLS-Prototype systems

• 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.

97
Jajodia - Formal Integrity Rules

• 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
• fo(D)?fo(R) ?fo(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 fo(rk)
  ?fo(ri)

98
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.

99
Formal Integrity Rules, cont.

• 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.

100
Multi-level Relation
Figure 15.1 The Relation Bookings with Primary
Key Flight
101
Multi-level Relation view of C user
Figure 15.1 The Relation Bookings with Primary
Key Flight
102
Multi-level relation view of U user

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

103
Polyinstatiation is necessary
104
Why Poli-instantiation?

• A low user tries to add information on flight
  GR555.
• If refused inference, if accepted violation of
  primary key constraint
• A high user attempt to change destination of
  flight
• AX301. If refused restricts access, if accepted
  violation of functional dependency
• Solution accept and include tuple class as part
  of the primary key!.

105
Polyinstatiated table after User U update
Figure 15.4 Updated Version of Table Data Given
in Figure 15.1.
106
Polyinstatiation Cont.

• Figure 15.5 Data Accessible to Confidential User

107
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

108
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.

109
Polyinstantiation Integrity
Assume query Dest NY and Seats 11 by C user
110
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.

111
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!

112
Statistical DB Security

• Statistical DB Contains information about
  individuals, but allows only aggregate queries
  (e.g., average age, rather than Joes 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 Joes age.
• Idea Insist that each query must involve at
  least N rows, for some N. Will this work? (No!)

113
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 X55 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 Joes age!

114
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

115
Example Database
116
Stat. DB security size restriction

• ???? ?????? ???? ??? ??????? ??? ??? ????? ??
  ???? ?????? ??? ?????? ???? ???? ?-1!
• ???? ?? ???? ????? ?? ???????? ?????
• Q1COUNT(LOCSF?LOC?SF)
• Q2COUNT(LOCSF?LOC?F)
• ?????? ??????? ??????? ???? 7 ??' ???????
  ?????.
• ?????? ??????? ?????? ???? 6 ?????? ?????? ???
  Q1-Q21
• ???? ???? ???? ?? ??? ???????? ?????
• Q3SUM(LOCSF?LOC?SFSAL)
• Q4SUM(LOC?SF?SEX?FSAL)
• ???????? ?????? ??? ????? Q4-Q3!

117
Stat. DB security size restriction

• ????? 7.5 ????? ???? ??? ???? ?? ??????
  ??????????? (??? ?? ???? ??? ???? ????? ?????
  ???????). ??? ?????? ?????? ???????? ????? ???
  ??????? ?? ???? ?????. ???? ?? ???? ?? ????? ???
  ?"? ?????? ????? ??????? (?"? ????? ????). ??????
  ????? ??? ??????
• function (Predicate Attribute)
• ???? function ??? ??????? ??? COUNT ?? SUM,
  ?-Attribute ??? ???? ????? ????? ????????.
• ??????, ???? ???? ?????? ?? ???? ???? ???????? ??
  Smith ??? ???? SF (?? ????????)???? ???.
• ??? ????? ???????? ?????
• COUNT (LOCSF . SEXF)
• ??? SUM (LOCSF
  . SEXFSAL)
• ???? ?? ??????? ?? Smith!

118
The individual Tracker

• Assume C characterize the individual uniquely
  then Q(C) or Q(CS) is unanswerable, S is the
  searched field.
• Assume CAB where both Q(A) and Q(AB) are
  answerable.
• Then Q(C)Q(A)-Q(AB) or
• Q(CS)Q(AS)-Q(ABS)

119
The Individual Tracker - Example

• CFCSProf, AF, BCSProf

120
The General Tracker

• Assume threshold is K.
• Find T such that
• 2k lt count(T) lt n-2k
• Then, k lt count(TC) lt n-k and
• k lt count(TC) lt n-k
• So, both are answerable!
• And Q(C) Q(TC) Q(TC) n !

121
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

122
Security of Linear Queries

• We consider queries of the form of eq. (3)
  applied to a database of N elements. All queries
  use the same value of k and the same weights aj.
• We observe first that, knowing one weight aj and
  one data element x, we can compromise the entire
  database. Let q1 and q2 be the responses to the
  two queries q1q(z1, , zj-1, x, zj1, , zk)
• q2q(z1, , zj-1, y, zj1, , zk)which differ
  only in their use of data elements x and y in
  the jth position.

123
Security of Linear Queries, cont.

• Equation (3) shows that (q1 q2) aj(x
  y)which can be solved for y. Now the entire
  database is vulnerable we pose q1 once and a new
  q2 for each of the N 1 unknown data elements,
  effecting a full compromise with N queries and N
  1 applications of eq. (4). As soon as two data
  elements, x and y, are known, we can also use eq.
  (4) to solve for any un known weight.

124
Security of Linear Queries, cont.

• Example 3 Suppose that the runners database
  implements the query q(z1, z2, z3) 0.2z10.5z2
  0.3z3
• A user knows that the weight of the first key is
  0.2 and that Smiths Max VOX is 68 thus the
  initial information is a1 0.2
• x11 68

125
Security of Linear Queries, cont.

• To determine Joness Max VOX, the user proceeds
  as follows. He poses the two queries q(x11, x12,
  x13), to which the system will respond,
  respectively,
• q1 407.6
• q2 406.2
• Equation (4) can be used to solve for x21 x21
  x11 (q1-q2)/a1
• 68 1.4/0.2
• 68 7
• 61which is Smiths Max VOX.

126
Runners Database
Max VOX is the maximum volume of oxygen
processable in milliliters per kilogram body
weight per minute
127
The Inference Problem Answering Queries
Without Revealing Secrets
is Mediocrates an Athenian?
yes
no
mum
k
is Mediocrates a Boeotian?
yes
mum
no
?k
is Mediocrates a Corinthian?
mum
yes
no
k
is Mediocrates a Dorian?
mum
no
yes
k
?k
K ? M is peaceable
128
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

129
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.

130
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.