Transcript Jajodia & Sandhu (1991),

The Jajodia & Sandhu model
• Jajodia & Sandhu (1991), a model for
the application of mandatory policies in
relational database systems. Based on
the sec classifications introduced in BLP.
It extends the standard relational model to
consider the sec classification.
• Multilevel relations: Schema and multiple
instances based on each access class. A multilevel relation consists of two parts:
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
(1) A state-independent multilevel relation
scheme R (A1, C1,…, Cn, TC), where each Ai
is a data attribute defined over domain Di,
each Ci is a classification attribute for Ai, and
TC is the tuple class attribute.
The domain of Ci is specified by a range [Li,
Hi] which is specified as a sub-lattice of
access classes.
The domain of TC is [lub (Li) , lub (Hi)].
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
(2) A collection of state-dependant relation
instances Rc(A1, C1,…, An, Cn, TC), one for
each access class c in the given lattice; each
instance is a set of distinct tuples of the form
(a1, c1, …, an, cn, tc) where
each element ai is either a value of domain Di
or null, each ci is a value of the specified
range and smaller than tc, that is, ci [ Li, Hi]
ci tc, and tc is the least upper bound of the
classes of the attribute in the tuple: that is,
tc = lub { ci: i=1, …,n}
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Example of a multilevel relation Employee
TS
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Instances at the S-level and TS-level of the Employee
relation
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Properties of the model:
Read and writes are controlled to the satisfaction of the No-Read-Up and
No-Write-Down principles. Other restrictions are put to regulate
polyinstantiation.
(1) Entity integrity: Let AK be the apparent key of a
relation R. A multilevel relation R satisfies entity integrity if,
and only if, for all instances Rc of R and t Rc
(1) Ai AK t[Ai] null
(2) Ai , Aj  AK  t[Ci]=t[Cj], ie. AK is uniformly
classified, and
(3) Ai AK t[Ci] t[CAK] (where CAK is defined as the
classification of the apparent key)
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Null values!
• Null values have two meanings:
– Corresponding to real null values or
– To attributes at a classification higher than the
classification of the instance.
• Two similar value tuples with different attribute sec
class (so hidden, turned to null)!
• Subsumtion relationship: t subsumes s, if for every
attribute Ai:
– t [Ai, Ci] = s [Ai, Ci] or
– t[Ai] != Null and s [Ai] == Null.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Properties of the model (cont.):
(2) Null integrity: A mutilevel relation R satisfies null
integrity if and only if for each instance Rc of R both the
following conditions are satisfied:
(1) For all t Rc, t[Ai] = null  t[Ci] = t[CAK]: that
is, null values are classified at the level of the key.
(2) Rc is subsumption free in the sense that it does
not contain two distinct tuples such that one
subsumes the other
A tuple t subsumes s if for every attribute Ai
- t[Ai, Ci] = s[Ai, Ci] or
- t[Ai] != null and s[Ai] = null.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Inter-instance integrity
Controlling the consistency among the different instances of a relation
A multilevel relation R satisfies inter-instance
integrity if and only if for all c´  c, Rc´ = (Rc, c´ ),
where the filter function  produces the c’instance Rc´ from Rc as follows:
(1) For every tuple t Rc such that t[CAK]  c´,
there is a tuple t´  Rc´, with t´[AK,CAK]=t[AK,CAK]
and for Ai AK
t´ [ Ai, Ci] = t [ Ai, Ci] if t [Ci]  c´,
&&
= <null, CAK> otherwise
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Inter-instance integrity (cont.):
(2) There are no tuples in R c´ other than
those derived by the above rule.
(3) The end result is made subsumption
free by exhaustive elimination of
subsumed tuples
.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
(4) Polyinstantiation integrity property:
A multilevel relation R satisfies Polyinstantiation
integrity iff, for every Rc, for all Ai:
(AK, CAK, Ci) Ai. That is, the apparent key, together
with the classification of the key and the
classification of the attribute functionally
determines the value of this attribute.
Informally: null integrity and interinstance integrity
ensure that, if a tuple value at some security level
can be filtered or derived from a higher-classified
tuple, then it is sufficient to store the higher
classified tuple in the multi-level relation.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
• Access to Multilevel relations:
– Deal with the write operations (Insert, Update,
Delete)
• Read is processed through the Read-Down
principle.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Insert operation:
The insert operation, from a c-user, has the following from:
INSERT INTO Rc [Ai [, Aj]…)]
VALUES (ai [, aj]…)
The insert operation is granted, if and only if, the following
conditions are satisfied:
(1) t [AK] does not contain any nulls
(2) For all u Rc : u [AK]  t[AK]
If the conditions are satisfied, the tuple is inserted into Rc and
all the instances Rc’>c
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Results of the operation INSERT VALUES “ John,
Dept2,20K” on S and TS instances of Employee from S
subject
S
S
TS Instance
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Update operation:
An update operation from a c user has the following
form:
UPDATE Rc
SET Ai = Si [, Aj = Sj]…
[WHERE P]
Where each si is a scalar expression, and p is a
predicate expression which identifies those tuples in Rc
that are to be modified
If the conditions are satisfied, the update is propagated
into Rc’>c according to the minimum propagation delay
policy: only those tuples which are needed to preserve
the inter-instance property are inserted in Rc’>c
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Results of the operation UPDATE salary = “30K” WHERE
Name = “Ann” on S and TS instances of Employee from TS
subject
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Result of the operation UPDATE Department= “Dept1” WHERE
Name = “Ann”” and S and TS instances of Employee from TS
subject
Sam
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Delete
• Propagation of Delete to Rc’>c
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
A multilevel relation to illustrate multilevel security
[ FIGURE 22.2 from ELMASRI, NAVATHE BOOK]
(a) The original EMPLOYEE tuples. (b) Appearance of EMPLOYEE after filtering for
classification C users. (c) Appearance of EMPLOYEE after filtering for classification U
users. (d) Polyinstantiation of the Smith tuple.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
The Jajodia & Sandhu model (cont.)
Some extensions have been proposed to the model in order to
solve the problem of polyinstantiation by eliminating entity
polyinstantiation* as follows:
(1) Make all keys visible (key class is equal to the lowest class
at which relation is visible)
(2) Partition the domain of the primary key (among various
access classes)
(3) Limit insertion to be done by trusted subjects only (the
system-high trusted user can insert)
(4) Use “restricted” values (when accessed by a user with
higher class; cannot update a restricted value)
_________________________________________________________________________________________
____
entity polyinstantiation: two tuples with same values for attributes in
the apparent primary key but a different key class.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Smith & Winslett model
• By: Smith & Winslett model, 1994
• All the databases share the same schema, and
each database is assigned a security class or
level. The database at a given level contains the
total beliefs of the subject of that level about the
state of the world reflected in the schema
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Smith & Winslett model (cont.)
A subject believes the contents of the database
at his/her own level.
A null value in a tuple means that the subjects
at that level believe that a value exists for that
attribute but do not know what that value is.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Smith & Winslett model (cont.)
Multilevel relations
Unlike the Sea View and the Jajodia models, the Smith &
Winslett model does not support classification at the level
of each single attribute. A mutlilevel relation is
characterized by a scheme R(K, KC, A1,…, An, TC) where
K is the set of key attributes, each Ai is an attribute in the
relation, and KC and TC are the security levels of the key
attribute and of the tuple respectively. Pair K, KC is
referred to as the identifier of the entity.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
QUERY PERATIONS(Smith/Winslett)
Different strategies for execution based on
belief level are specified:
UPDATE R
SET ATTR = value
WHERE <predicate p>
BELIEVED BY L
===================
UPDATE EMPLOYEE
SET SALARY = “30k”
WHERE SALARY =“20K”
BELIEVED BY Anyone
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Discussions on mandatory models
Advantages:
• Suitability to certain kinds of environments where the users
and objects can be classified.
• Providing a high level of certification for security, being
based on unforgeable labels. Problems like Trojan Horse
can be avoided.
Disadvantages:
• Being too rigid and inapplicable to some environments
• Not always possible to assign clearances to users of a
commercial information systems or to assign sensitivity
levels to data.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Confinement (‫)تحدید‬
• Is the problem of preventing a server from leaking
info that the user of the service considers
confidential.
• A process that does not store data, cannot leak it.
• Observing the flow of control can deduce info
about the input.
•  A process than cannot be observed and
communicate with the others, cannot leak info.
….. Total isolation.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Covert channel
• The problem is that total isolation is
impossible. Unconfined processes can
transmit data over the shared resources.
• A covert channel is a path of communication
that was not designed for communication.
• Transitive confinement. If p is confined to
prevent leakage, the calling process q can
also be confined to leak.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Covert channel
• Two types of covert channels:
1-Use of storage to transmit info.  the
model should control all accesses to the
storage. If it fails, covert channel arise.
2-All processes can obtain a rough idea of
time time is a communication channel. All
processes can read time and can write time.
 a shared resource.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Isolation
• Virtual Machine: simulating a computer
system. JVM
• Analyzing all actions against leaking of info:
SANDBOX
A sandbox is an environment in which the
actions of a process are restricted according
to the security policy. E.g. JVM
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Database Security Design
• Previously we discussed the concepts of
logical database security.
• Now we focus on the design of logical DB
security measures.
• Having a secure DB should be considered
from the early stages of the application
development.
• Design methodology is required.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
• In all phases of a DB design, security
issues should be considered:
– Analysis,
– Conceptual design,
– Detailed design,
– Implementation,
– Test,
– Maintenance.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Secure DBMS design
• A set of mechanisms at the OS and DBMS
level.
• Some of the mechanisms can be used from
the OS side.
• Security can not be added as an extension!
• Difference between OS and DBMS
concerning security:
– Object granularity: file vs relation, row, tuple, …
– Semantic correlations among data in DBMS
– Metadata, which exists in DBMS
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
• Sensitivity of metadata, should be protected.
• No metadata in OS.
– Logical and physical objects: objects in OS are physical
and in DBMS are logical. file vs view
– Multiple data types: multiple data types and multiple
access modes (statistical mode, administrative mode) vs the
OS level which implies R, W,X for physical access.
– Static & dynamic objects: Physial objects in OS vs views
in DBMS. Special protection is needed for dynamic objects.
– Multi-level transactions: transactions involving different
security levels. Such transactions must run securely.
– Data life cycle. In DBMS, data has a long life cycle.
Protection must be assured throughout the whole
lifetime of the data.
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
Security Mechanisms in DBMS
The main security mechanisms that a DBMS should
provide:
• Different degrees of granularity of access:
– relations, tuples, database, …
• Different access modes, read is differentiated from write.
• Different types of access controls, for an access request
–
–
–
–
–
Name-dependent, control based on the objects name
Data-dependent: control based on the objects contents.
Context-dependent: date, time, ….
History-dependent
Result-dependent: control based on the query results …
Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.
• Dynamic authorization: DBMS should support the modification
of users’ authorizations while the DB is operational.
• Multi-level protection:
– Security labels and assigning them to subjects and
objects. In the same object, different sec labels can be
assigned to different data items.
• Covert channels-free. Users should not be able to obtain
unauthorized info through indirect methods of comm.
• Inference control
• Polyinstantiation: multiple instances of the same data
item, each having its own classification level.
• Auditing. Auditing info is also useful for inference
control.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• No back doors, access only through DBMS!
• Uniformity of mechanisms
• Reasonable performance !!!
• ALSO, some basic principles of information
integrity is required which are independent of the
content. … next page ….
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Basic principles of Information Integrity
• Well-formed transactions instead of arbitrary
procedures
• Authenticated users: change should be
executed only by auth users.
• Least privilege: the need-to-know principle
• SoD
• Continuity of operation, through replication …
• Reconstruction of events, through before-image or
after-image
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
System R Authorization Model
•
•
•
•
•
The very first DBMS, developed by IBM.
Tables, as objects to be protected.
Base tables or views
Subjects are the users who access the DB.
Access modes applicable to the DB tables:
–
–
–
–
–
Read
Insert
Delete
Update
Drop: delete an entire table
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• The model supports a decentralized admin
of authorizations.
• The creator user has all the rights (fully
authorized) to execute privileges on the
table or grant the others to have access. It is
not the case for views.
• As a result, a new authorization may be
inserted into the set of authorizations.
• Privileges can be given with the grant option
to the other users.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• Each authorization can be characterized as a
tuple <s, p, t, ts, g, go>
s: is the subject or the grantee
p: privilege (access mode)
t: table
ts: time of granting the auth.
g: grantor
go  {yes, No}: if the grantee has the grant option.
Example: <B, select, T, 10, A, yes>
<C, select, T, 20, B, no>
C cannot grant the other users granting of the select
privilege.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• Existence of the grantor and the time of
grant is the way we revoke, described later.
• The grant command in SQL:
GRANT All-Rigths/<privileges>/All but
<privileges> on <table> TO <user-list>/PUBLIC
[WITH GRANT OPTION]
• Users having the grant access, can also
revoke the privilege on the table (which they
have granted).
REVOKE All-Rights/<privileges> ON <table>
FROM <user-list>
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Revoke Mechanism
• System R enforces recursive (or cascading)
revocation.
• Revocation of p on t from user y by user x is
defined as if all the authorizations from p on
t granted by x to y had never been granted.
 all the effects of the grant should be removed.
• As an example, next slide
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
10
B
40
30
A
E
70
G
D
20
C
50
60
F
B has granted a privilege to D, who has passed it to E, who has passed it to G
10
B
A
D
20
C
50
B revokes D’s privilege
60
F
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Views
• Views on top of the base tables.
• A single and effective mechanism to
support content-dependent authorization.
• e.g. User B creates table B and want to
grant user A the authorization for just
tuples with salary > 1000.
– What should be done??
Defining the view “select * from T where
a1>1000 and then grant B the read
authorization on the view
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Views
• Privileges on views in comparison with privileges
on the base tables??
– Depends on the view semantics.
• Definitely, having a privilege on a view depends on
having that on all tables directly referenced by the
view. View on a single table or on multiple!
• Depending on the view semantics, the view owner
may have more restricted than on the base tables.
• Privileges of the view owner determined at the
time of view definition.
Timestamp is the time of view definition.
• The grantor of the view, is whom has been
assigned as the owner of the view at the definition
time.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Implementation of the model
• Two relations named: SYSAUTH and SYSCOLAUTH
• SYSAUTH has the following attributes:
–
–
–
–
–
–
–
–
–
•
UserId: who has the authority
Tname
Type: R or V
Grantor
Read: The time at which the grantor granted the read
privilege. Default is 0
Insert: The time …
Delete: The time …
Update: the columns on which the privilege is
granted. It may have All or None or Some values
Grantopt: the Grant operation ….
Fig 4.2 corresponding to Figure 4.1 (a)
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• In the revised version, if two similar grants are
happened, two records are inserted with
different timestamps.
• SYSCOLAUTH: If there is specified “some” in the SYSAUTH
update column, a tuple is needed for each column
– UserId
– Table
– Column
– Grantor
– Grantopt
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Extension of the model
• 1982 by Wilms and Linsday to consider group
management.
• Set of users in a group.
• Groups may overlap.
• Applied in System R*, the distributed DBMS.
• Another extension: having cascadable revoke or
non-cascadable revoke!
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Non-cascade revoke
10
B
40
30
A
E
70
G
D
20
C
50
60
F
B has granted a privilege to D, who has passed it to E, who has passed it to G
10
40
B
A
E
70
G
60
D
20
C
50
60
F
B revokes D’s privilege
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Main features of a Secure DB Arch.
• SDBMSs operate according to two possible
modes:
– System-High or
– Multilevel
• In System-High DBMSs, all the users are cleared
to the highest security.
• Before releasing data, a guard must review such
data in order to properly release them.
• This model has the risk for security, as all users
are cleared to the highest clearance level.
• It is simple!! Can use existing DBMSs.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Multi-level mode
• Based on using trusted and untrusted
DBMSs.
– Trusted Subject Archs
• Using a trusted DBMS and a trusted OS
• From scratch or extension of the security features.
– Woods Hole Archs, where an untrusted DBMS is
used with an additional trusted filter
• Integrity Lock
• Kernelized
• Replicated
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Architecture
Research prototype Commercial DBMS
Integrity Lock
Mitre
TRUDATA
Kernelized
SeaView
Oracle
Replicated
NRL
Trusted Subject
A1 Secure DBMS
Sybase
Informix
Ingres
Oracle
DEC
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Trusted Subject Arch
• Figure in the next slide.
• A set of untrusted front ends is used to interface
with different clearances (Low and High).
• TDBMS and TOS form a single TCB (Trusted
Computing Base)
• DBMS is responsible for multi-level protection of
DB objects.
• High level dominates the low-level.
• DBMS subjects and objects are assigned DBMS
labels and so trusted and exempted from OS
mandatory controls.
• Sybase adopts this solution by assigning tuplelevel labels.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
High user
low user
Untrusted Front end
Untrusted Front end
Trusted DBMS
Trusted OS
Database
(DBMS & NON-DBMS
DATA)
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Woods Hole Archs
• General arch is fig 4.5
• A set of untrusted front ends
• It then interface with a monitor (trusted front
end) which cannot be bypassed.
• It interfaces an untrusted back end.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
High user
low user
Untrusted Front end
Untrusted Front end
Trusted front end
(reference monitor)
UnTrusted DBMS
Database
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Integrity Lock Arch
•
Figure 4.6
• Connected via UFE performing pre and post processing
of queries.
• An TFE (Trusted filter) is inserted between UFEs and the
untrusted DBMS.
• TFE is responsible for enforcing sec functions and multilevel protection.
• Stamp contains sec label and other relevant control data.
Stamps are generated and verified by the TFE.
• TFE responsible for generating audit records.
• The problem is leakage of unauthorized info and also
inference.  selection, projection and … must be
handled in TFE or UFE!! Not in the DBMS
•
Figure 4.7
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
High user
low user
Untrusted Front end
Untrusted Front end
Trusted Filter
Cryptographic Unit
Append
Stamp
Query
Store
Check
Stamp
Response
UnTrusted DBMS
Database
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Kernelized Arch.
• Figure 4.9
• Trusted OS is used, responsible for the
physical access in DB and enforcing
mandatory access control.
• DB objects have similar sec labels stored in
trusted OS.
• Converting multi-level relations into single
level relations access.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
High user
low user
Trusted front end
Trusted front end
High DBMS
Low DBMS
Trusted OS
Database
(High & Low)
data
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Replicated Arch.
• Figure 4.10
• Expensive.
• No implementation in real business.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
High user
low user
Trusted front end
Trusted front end
High DBMS
Low DBMS
Database
(High & Low)
data
Database
(Low data)
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Research Prototypes
• SeaView
• SeaView implements the Sea View security
model using a kernelized arch.
• Designed to satisfy the A1 classification of
DoD (verification design).
• Jointly by Oracle, SRI, and Gemini.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• Five layers:
• 1- GEMSOS TCB
• A Mandatory Security Kernel (GEMSOS security
kernel) + the Non-Mandatory TCB.
• GEMSOS security kernel implements the
requirement for mandatory policy.
• Enforces the mandatory sec policy through a labelbased mechanism.
• Has 8 protection rings:
– Ring attributes are assigned to each object.
– A ring number is assigned to each subject.
– A subject can access an object if its ring number is
consistent with the object ring attribute.
• The Non-Mandatory TCB is responsible for audit
and group management.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
2- Resource Manager is responsible for
providing the requirements of the Oracle
DBMS and Sea View.
– It is a special-purpose OS outside the TCB,
since the TCB should have the minimal
design.
– Funcs: Creation of the file system, high-level
device drivers, mapping of the high-level
objects of DBMS to low-level objects of the
OS.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
3- Oracle Mandatory Prototype:
– Management of the single-level objects.
– Composed of the Oracle Run-Time environment +
rewritten Oracle utilities
– Oracle pre-processor for supporting execution of
embedded SQL.
4- MSQL processor:
– Dealing with multi-layer relations.
– Converting embedded SQL into normal SQL
statements.
– It is an special SQL designed for SeaView, to deal
with multilevel relations.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• 5- SeaView Users layer composed of the
functions required to manage the DB that
can be left untrusted.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
A1 Secure DBMS
• ASD is a multilevel secure relational DBMS designed in
1992.
• A prototype is available.
• Objective: meeting the A1 criterion of DoD classification.
• Developed by the ADA language.
• On top of the A1secure OS.
• Permits interconnection of the trusted and un-trusted
systems.
• It guarantees that data has been protected via both
mandatory and discr. access control rules.
• Only one copy of data is stored in the system, accessed by
different sec levels.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
ASD
• Can work in 3 different modes
– As a DBMS server on a LAN
– As a back-end DBMS for a host computer
(single-level and multi-level)
– As a host-resident DBMS.
• Fig 4-12 (to be drawn on the board)
• Comm between untrusted processes is done
through TCB.
• Enforces both BLP and Biba rules.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Commercial Products
•
•
•
•
•
•
Ingres
Oracle
Sybase (Sybase secure server)
Informix
SQLBase
Table 4.2 page 266
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Design of Secure DBs
• As the secondary requirement: most cases.
 security is added as a library.
• As the primary requirement.
• Methodologies for secure software
development is normally used in this case.
• Some cases OS security features are
utilized.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
DoD guidelines
• Methodology for secure DB design:
•
•
•
•
•
Preliminary analysis
Security requirements and policies
Conceptual design
Logical design
Physical design
– Figure 4.13
– Separating security policies from security
mechanisms.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• Preliminary analysis
– System risks
– Features of the database environment: single
level or multi-level security support.
– Applicability of existing security products
– Integrity of the security products
– Performance of the resulting security system
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Requirement analysis and sec
policy selection
• Protection needs for different types of risk are
different for different database systems.
• Sensitivity of information.
• High-risk and low-risk systems.
• Data accessibility of who has access to which
data.
• Number and types of users.
• Reliance of security on the selected technologies.
• Degree of vulnerability to which the environment is
exposed.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Security policy selection
•
•
•
•
•
•
•
•
•
Secrecy vs integrity vs reliability
Maximum sharing vs minimum privilege
Granularity of control
Attributes used for access control: S/O, location,
time, …
Integrity
Priorities
Privileges
Authority
Inheritance
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Conceptual design
• Designed through
– Identification of subjects and objects
– Identification of access rights granted to Ss over Os.
– Analysis of the propagation of authorizations in the
system through grant/revoke privileges.
• Should be
– Complete, of all security requirements initially stated
– Consistent, if there should be no access, should not be
directly or indirectly.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Logical and physical design
• Logical design, mapping of the conceptual
design into a logical model supported by the
specific DBMS being used; e.g. considering
views, queries, …
• Physical design, how to implement access
rules and their relationship with the physical
structure of DB.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Recommendation of implementing
security mechanisms.
• Economy of mechanisms: simplicity as much as
possible.
• Efficiency
• Linearity of costs, the operation cost should be
proportional to the actual use of the mechanism
• Privilege separation (responsibilities)
• Minimum privilege.
• Complete meditation
• Known design. Sec techniques should be well
known for the client.
• Security by default.
• Minimum common mechanisms: Mutual
independence between mechanisms.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• Psychological acceptability: easy to use, avoiding heavy
restrictions  users to encourage protection, not trying
to disable it!!
• Flexibility: having different policies
• Isolation: isolation of security mechanisms from the other
components, so more resistant.
• Verifiability
• Completeness and consistency
• Observability: the mechanism and the possible attacks
against it should be controllable.
• Problem of residuals: residuals (from the terminated
processes) must be erased.
• Invisibility of data: if a user is unauthorized to access
data must be unauthorized about the structure of data.
• Work factor: too much effort to break a mechanism
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
• Intentional traps: Monitor the behavior
and the sources of attacks.
• Emergency measures
• Secure hardware
• Programming language, the language, its
compiler, …
• Correctness
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.
The person relation schema for illustrating
statistical database security
[ FROM ELMASRI/NAVATHE FIGURE 22.3]
Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.