The Jajodia Sandhu model Jajodia Sandhu 1991 a

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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

(1) A state-independent multilevel relation scheme R (A 1, C 1, …, 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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

The Jajodia & Sandhu model (cont. ) (2) A collection of state-dependant relation instances Rc(A 1, C 1, …, An, Cn, TC), one for each access class c in the given lattice; each instance is a set of distinct tuples of the form (a 1, c 1, …, 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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

The Jajodia & Sandhu model (cont. ) Example of a multilevel relation Employee TS Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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, 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; 2 nd 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; 2 nd 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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

The Jajodia & Sandhu model (cont. ) Results of the operation INSERT VALUES “ John, Dept 2, 20 K” on S and TS instances of Employee from S subject S S TS Instance Rasool Jalili; 2 nd 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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

The Jajodia & Sandhu model (cont. ) Results of the operation UPDATE salary = “ 30 K” WHERE Name = “Ann” on S and TS instances of Employee from TS subject Rasool Jalili; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

The Jajodia & Sandhu model (cont. ) Result of the operation UPDATE Department= “Dept 1” WHERE Name = “Ann”” and S and TS instances of Employee from TS subject Sam Rasool Jalili; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

Delete • Propagation of Delete to Rc’>c Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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, A 1, …, 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; 2 nd 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 = “ 30 k” WHERE SALARY =“ 20 K” BELIEVED BY Anyone Rasool Jalili; 2 nd 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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd 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 is a communication channel. All processes can read time and can write time. a shared resource. Rasool Jalili; 2 nd 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; 2 nd semester 1387 -1388; Database Security, Sharif Uni. of Tech.

Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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 info is also useful for inference control. Rasool Jalili; 2 nd 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; 2 nd 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 • So. D • Continuity of operation, through replication … • Reconstruction of events, through before-image or after-image Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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 a 1>1000 and then grant B the read authorization on the view Rasool Jalili; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

Implementation of the model • Two relations named: SYSAUTH and SYSCOLAUTH • SYSAUTH has the following attributes: – – – – – • User. Id: 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; 2 nd 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 – User. Id – Table – Column – Grantor – Grantopt Rasool Jalili; 2 nd 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; 2 nd 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 20 D C 50 60 F B revokes D’s privilege Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

Architecture Research prototype Commercial DBMS Integrity Lock Mitre TRUDATA Kernelized Sea. View Oracle Replicated NRL Trusted Subject A 1 Secure DBMS Sybase Informix Ingres Oracle DEC Rasool Jalili; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

High user low user Untrusted Front end Trusted DBMS Trusted OS Database (DBMS & NON-DBMS DATA) Rasool Jalili; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

High user low user Untrusted Front end Trusted front end (reference monitor) Un. Trusted DBMS Database Rasool Jalili; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

High user low user Untrusted Front end Trusted Filter Cryptographic Unit Append Stamp Query Store Check Stamp Response Un. Trusted DBMS Database Rasool Jalili; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

High user low user Trusted front end High DBMS Low DBMS Trusted OS Database (High & Low) data Rasool Jalili; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

Replicated Arch. • Figure 4. 10 • Expensive. • No implementation in real business. Rasool Jalili; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

High user low user Trusted front end High DBMS Low DBMS Database (High & Low) data Database (Low data) Rasool Jalili; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

Research Prototypes • Sea. View implements the Sea View security model using a kernelized arch. • Designed to satisfy the A 1 classification of Do. D (verification design). • Jointly by Oracle, SRI, and Gemini. Rasool Jalili; 2 nd 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; 2 nd 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; 2 nd 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 Sea. View, to deal with multilevel relations. Rasool Jalili; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

• 5 - Sea. View Users layer composed of the functions required to manage the DB that can be left untrusted. Rasool Jalili; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

A 1 Secure DBMS • ASD is a multilevel secure relational DBMS designed in 1992. • A prototype is available. • Objective: meeting the A 1 criterion of Do. D classification. • Developed by the ADA language. • On top of the A 1 secure 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

Do. D 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.

Rasool Jalili; 2 nd 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; 2 nd semester 1384 -1385; Database Security, Sharif Uni. of Tech.