The jajodia sandhu model
This presentation is the property of its rightful owner.
Sponsored Links
1 / 84

The Jajodia & Sandhu model PowerPoint PPT Presentation


  • 415 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

The Jajodia & Sandhu model

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The jajodia sandhu model

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 multi-level relation consists of two parts:

Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.


The jajodia sandhu model

(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

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 cont1

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 cont2

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 cont3

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!

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

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

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

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

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


The jajodia sandhu model

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

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]

Ifthe 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 cont6

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 cont7

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

Ifthe 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 cont8

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 cont9

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

Delete

  • Propagation of Delete to Rc’>c

Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.


The jajodia sandhu model

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 cont10

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

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

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 cont1

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

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

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.


The jajodia sandhu model

Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


Confinement

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

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 channel1

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

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.


The jajodia sandhu model

Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


Database security design

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.


The jajodia sandhu model

  • 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

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.


The jajodia sandhu model

  • 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

    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.


    The jajodia sandhu model

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


    The jajodia sandhu model

    • 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

    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

    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 jajodia sandhu model

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


    The jajodia sandhu model

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


    The jajodia sandhu model

    • 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

    Revoke Mechanism

    • System R enforces recursive (or cascading) revocation.

    • Revocation of p on t from user y by user xis 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.


    The jajodia sandhu model

    70

    E

    G

    B

    40

    10

    30

    A

    D

    20

    50

    60

    C

    F

    B has granted a privilege to D, who has passed it to E, who has passed it to G

    B

    10

    A

    D

    B revokes D’s privilege

    20

    50

    60

    C

    F

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    Views

    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.


    Views1

    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

    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.


    The jajodia sandhu model

    • 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

    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.


    The jajodia sandhu model

    Non-cascade revoke

    70

    E

    G

    B

    40

    10

    30

    A

    D

    20

    50

    60

    C

    F

    B has granted a privilege to D, who has passed it to E, who has passed it to G

    40

    70

    G

    B

    E

    10

    A

    60

    D

    20

    50

    60

    C

    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

    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

    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.


    The jajodia sandhu model

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    Trusted subject arch

    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 tuple-level labels.

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    The jajodia sandhu model

    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

    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.


    The jajodia sandhu model

    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

    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 multi-level 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.


    The jajodia sandhu model

    High user

    low user

    Untrusted Front end

    Untrusted Front end

    Trusted Filter

    Cryptographic Unit

    Check

    Stamp

    Append

    Stamp

    Query

    Store

    Response

    UnTrusted DBMS

    Database

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    Kernelized arch

    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.


    The jajodia sandhu model

    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

    Replicated Arch.

    • Figure 4.10

    • Expensive.

    • No implementation in real business.

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    The jajodia sandhu model

    High user

    low user

    Trusted front end

    Trusted front end

    High DBMS

    Low DBMS

    Database

    (Low data)

    Database

    (High & Low)

    data

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    Research prototypes

    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.


    The jajodia sandhu model

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


    The jajodia sandhu model

    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.


    The jajodia sandhu model

    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.


    The jajodia sandhu model

    • 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

    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.


    The jajodia sandhu model

    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

    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

    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

    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.


    The jajodia sandhu model

    • 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

    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

    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

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

    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.


    The jajodia sandhu model

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


    The jajodia sandhu model

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


    The jajodia sandhu model

    Rasool Jalili; 2nd semester 1384-1385; Database Security, Sharif Uni. of Tech.


    The jajodia sandhu model

    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.


  • Login