1 / 84

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.

rhys
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. The Jajodia & Sandhu model (cont.) Example of a multilevel relation Employee TS Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.

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

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

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

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

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

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

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

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

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

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

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

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

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

  18. Delete • Propagation of Delete to Rc’>c Rasool Jalili; 2nd semester 1387-1388; Database Security, Sharif Uni. of Tech.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related