Discretionary Vs. Mandatory

Transcription

1 Discretionary Vs. Mandatory Discretionary access controls (DAC) Privilege propagated from one subject to another Possession of an access right is sufficient to access the object Mandatory access controls (MAC) Restrict access on the basis of security labels Inherent Weakness of DAC Unrestricted information flow from one object to another Ali owns file A and grants read to Taghi Taghi reads file A and write to file B Ali has no control over file B uppose users can be trusted How about software? Trojan horses 1

2 Military ecurity Requirements Protect data from unauthorized modification Protect data from unauthorized access trong information flow control Protect system from attacks resulting in a loss of service 2

3 Mandatory Access Controls Enforce a label-based policy: Assign security levels to all data Assign a security clearance to each user DBM should make sure that all users have access to only those data for which they have a clearance Mechanisms Reference Monitor It contains security classes of all objects and subjects. Whenever a subject accesses an object, it must do so via the reference monitor. It enforces the two model restrictions faithfully. It is always running, cannot be bypassed, and cannot be tampered with. 3

4 MANDATORY ACCE CONTROL MODEL Bell-LaPadula Model Bell and Lapadula, 1976 is an extension of the access matrix model oriented to the definition of the security requirements in complex systems where system elements can be classified. Initially oriented to protection in the O env, faces the problem of information secrecy. Each security level is described by two components: a classification and a set of categories. The classification is an element of the set T,, C, and U. T>>C>U. The set of categories is a subset of non-hierarchical set of elements; may be an application or organization descriptor (e.g., financial, educational, etc.) 4

5 Bell-LaPaduala Model (cont.) Classification Levels for subjects/ programs and objects/resources: 1-Top secret 2- ecret 3- Confidential 4- Unclassified ecurity Levels: L 1 = (C 1, 1 ), L 2 = (C 2, 2 ) 1 and 2 are categories. L 1 is higher or equal to L 2, if and only if: C 1 > C Lattice of the ecurity levels in the next slides 5

6 6

7 7

8 8

9 Bell-LaPaduala Model (cont.) The model is based on the subject-object paradigm: subjects are active elements that can execute actions; objects are passive elements that can contain information. ubjects are processes acting on behalf of users, who are assigned a sec level called clearance. This is the level of trust to the user. It is assumed that the user does not disclose info to those not holding the appropriate clearance. The sensitivity of the info stored in objects, specifies their sec level. 9

10 Model considers 4 access modes executable by subjects on objects: Read-only or Read Append (writing without reading) Execute (executes an object /program) Read-write or Write The creator of an object is considered as its owner and so is allowed to grant and revoke authorization on the object to other users. The ownership is not transferable. The ystem tate The state of the system is described by the 4-tuple (b,m, f, H), where: b: the current access set; (s, o, m): subject s has current access mode m on object o. M: the access matrix; M (s, o)- same as the access/matrix model- specified the access modes subject s is authorized for an object o. f: a level function that associates with each subject & object in the system its security level f: O U L To each object only one sec level is associated. 10

11 To each user, 2 sec levels are associated: its clearance (f s ) (the sec level assigned when it is created) and its current level (f c ) (the sec level at which the user is actually operating. It may change during the subject s life time, but always: f c (s) H f s () This means that the user can log into the system at any sec level which is dominated by the user clearance. H: The current objects hierarchy. This is needed to specify the dominance relationship between security levels. Bell-Lapaduala Model (cont.) The system state can be changed by executing operations. The operations are: Get access : initiate access to object in a given mode. The execution of this operation modifies the triple <s,o,m> Release access : terminate access previously started by get. The triple is removed as the current access. Give access: grant an access mode on an object to a subject. This operation changes the access matrix by inserting the access mode being granted. If the insertion respects the axioms of the mandatory policy. Rescind access : revoke access previously granted with the give operation. 11

12 Bell-Lapaduala Model (cont.) Operations - contd.: Create object: an object may be inactive or active; this operation takes an inactive object and adds to the object hierarchy. Delete object: deactivates an active object from the hierarchy. Change subject security level, changes f. Change object security level, changes f. Only on the inactive objects, and only upgrading the object security level. The new security level of the object must be dominated by the subject requesting the change clearance. Bell-Lapaduala Model: Axioms A system state is secure, iff it satisfies a set of properties. This is controlled by a reference monitor. A trusted subject is a subject that can be relied on not to compromise security. ome constraints are enforced only on requests made by untrusted subjects. (1) imple security (ss) property: A subject may have read or write access to an object only if the clearance of the subject dominates the security level of the object. A system state v= (b, M, f, H) satisfies the ss-property iff for each M[s,o] containing the read or write access modes, f s (s) f o (o). The aim of this property is to prevent subjects from reading info having the higher classification than the subject s clearance. 12

13 BLP Axioms: tar (*) property An untrusted subject may have append access to an object, if the security level of the object dominates the security level of the subject. (f o (o) f c (s)) An untrusted subject may have write access to an object if only the security level of the object is equal to the current security level of the subject. (f o (o) =f c (s)) An untrusted subject may have read access to an object only if the security level of the object is dominated by the current security level of the subject. f c (s) f o (o). BLP Axioms: tar (*) property A system state v= (b,m,f,h) satisfies the *-property iff s (where ) is the set of untrusted subjects and oo: append M[s,o] f c (s) & f o (o). write M[s,o] f c (s) = f o (o). read M[s,o] f c (s) f o (o). atisfaction of the *-property includes the ssproperty. Note that f s (s) f c (s). Both the ss-property and the *-property are required. ss-property is needed for all subjects; while the *-property is required for untrusted subjects. 13

14 BLP summary UMMARY IN IMPLER TERM; two basic principles: a subject can only read objects whose sec level is dominated by the level of t he subject f s (s) f o (o).. NO READ-UP ECRECY. a subject can only write objects whose sec level dominates the level of t he subject f s (s) & f o (o).. NO WRITE-DOWN ECRECY. These principles have been adopted by all MAC policies, as they controls the flow of info ensuring info not to be accessible by subjects not having the necessary clearance. BLP summary (cont.) (3) Tranquility principle No subject can modify the classification of an active object (4) Discretionary property (ds-property) Every current access must be present in the access matrix: that is, a subject can exercise only accesses for which it has the necessary authorization. A system state satisfies the discretionary property if and only if for all subjects s, objects o, and access mode m: < s, o, m> b m M [s,o] 14

15 BLP extension (5) Non-accessibility of inactive objects A subject cannot read the contents of inactive object (6) Rewriting of inactive objects A newly activated object is assigned an initial state independent of the previous activations of the object. Although proposed back in 1976, this model still dominates the design of the secure trusted database implementations by vendors for military/government applications following Mandatory Access Control. Biba model BLP and other information-flow based security definitions address confidentiality, what about integrity BLP does not protect the system from unauthorized modification of info. Biba (1977) model is aimed to protect info integrity What does integrity mean? data not changed in incorrect ways Difference between confidentiality & integrity a subject cannot leak a piece of confidential information without reading it, but can introduce low-integrity information without reading any some trust has to be placed on subjects for integrity. 15

16 Biba Model The bases of the Biba model is similar to that of BLP. Notation of ubject and Objects and their classification. ubjects are active entities Objects are passive entities Each O and is assigned a classification named an integrity level. The integrity level assigned to an object reflects both the degree of trust that can be placed on the object info and the potential damage that could result from unauthorized modification of the info. Biba Each integrity level has two elements: A classification Crucial Very Important Important C > VI > I A set of categories A subset of a non-hierarchical set Integrity levels form a lattice with respect to the Partial Order dominance relationship (). 16

17 Biba L1 = (C1, 1), L2= (C2, 2) L1 L2 iff C1 C2 && 1 2 L1 > L2 iff C1 > C2 && 1 2 Incompatibility: neither L1 L2 nor L2 L1 The integrity level of a subject is its belonging user s integrity level reflect the user trustworthiness for inserting, deleting, and modifying info. The integrity level of an object indicates the level of trust that can be placed in the object and the potential damage that could result from unauthorized modification of the info. Biba: Access modes The model considers the access modes: Modify: to write info in an object, similar to write. Invoke: Allows subjects to communicate Observe: to read info from an object. Execute: to execute an object (program) No access mode for administration of authorization: Ownership is not considered in the Biba model. 17

18 Axioms No administration operation for grant or revoke in the model. Direct modification of the ACLs associated with the objects. A family of policies are proposed in Biba, each adopting different conditions to ensure info integrity. Two major groups: nondiscretionary and discretionary policies. Non-Discretionary Policies Determines accesses executable by the subjects on the objects basis on their security levels; includes the following policies: 1. Low-watermark policy for subjects; axioms: A subject can hold the modify access to an object if its integrity level that of the object. A subject can hold the invoke access to another subject if the integrity level of the first subject that of the other subject. 18

19 A subject can hold the observe access to whatever object. After observing of a subject on an object, its integrity level = the greatest lower bound between the subject and the object integrity level (before the operation). This policy is said to be dynamic; since it possibly decreases the integrity level of a subject upon each observing objects with lower or incompatible integrity levels. Main drawback: order of the operation yields different results! Accessing after observe or before observing an object differs! 2- Low-watermark policy for objects A subject can hold the modify access to objects at whatever integrity level. After each modify access of on O, the integrity level of O is set to the greatest lower bound between the integrity levels of and O (before access). The policy is dynamic. The integrity level of objects is decreased based on the modifier. Allows improper modifications! When a modification is done, the int level of the object is downgraded, but exposing to threats. The scenario may not be recoverable! 19

20 3- Low-watermark integrity audit policy: A subject can modify objects at whatever integrity level. If modifies O at higher or incompatible integrity level, the sec violation is recorded in an audit trail. The policy does not prevent improper modifications. 4- Ring policy: Int. levels of subjects and objects are fixed during their lifetime. It is based on the following axioms: can hold the modify access to O if the int. level of the int. level of O. can hold the invoke access to if the int. level of H the int. level of! can hold the observe access to objects of whatever int. level. Improper modification can occur indirectly. A highlevel subject can observe an object (at whatever level) and then modify an object at its own int level. 20

21 5- trict integrity policy: Integrity *-property: can hold the modify access to O if the int level of the int level of O. Invocation policy: can hold the invoke access to if the int level of the int level of. imple integrity condition: can hold the observe access to O only if its int level H the int level of O. The policy prevents from the transfer of info from lowintegrity object to objects at higher int levels. ummary of the trict integrity policy: No Read-Down integrity No Write-Up integrity Discretionary Policies in Biba Access Control Lists: Each object has an access control list indicating the subjects that can access the object. Modification of the ACL can be done by subjects who have the modify access on that object. Objects hierarchy: Organization of objects through a rooted tree structure: To access an object, a subject must have observe access to all its ancestors. Ring: Each subject is assigned a privilege attribute (ring) Low number rings are higher privileged. Accesses are allowed based on the allowed range of rings. A subject can hold the modify access on objects in an allowed range of rings. A subject can hold the invoke access to subjects of greater privilege only in an allowed range of rings. A subject can hold the invoke access on any subject with lower or equal privilege. A subject can hold the observe access on objects in an allowed range of rings. 21

22 ummary of Biba s Models Different models assume different kinds of trust in subjects the ring model assumes subjects can correctly process inputs and generate data of a certain integrity level the low-water mark models assume subjects do not introduce low integrity information themselves, but may be contaminated by the source the strict MAC model assumes subjects may be contaminated by the source and can only generate data of a certain integrity level Key Difference between Confidentiality and Integrity Noninterference policies for protecting data confidentiality, constraining: Who can read the secret data. Where the secret data will flow to (in the future). Dually, integrity policies constrain: Who can write to the data. Where the data is derived from (in the past, the history of the data)." 22

23 Key Difference between Confidentiality and Integrity????? For confidentiality, no trust needs to be placed on subjects one does need trusted subjects to make system realistic, but they are not needed for confidentiality For integrity, one has to trust subjects therefore; one has to justify such trust Dion Model (1981) Proposed as a mandatory policy which protects the secrecy and integrity together. Combines the principles of the BLP and Biba models (strict consistency policy) No discretionary policy in the model. Does not allow info transfer from objects to subjects (through the write operations) Data flow is only allowed between objects, never between objects and subjects. Introduction of the concept of Connection between objects to flow info between them. 23

24 ubjects are entities executing in the system on behalf of users. Each system object is assigned 3 sec levels and 3 int levels AL (Absolute sec level) specified upon creation and fixed for the whole life of the subject. It is the sec level of the user corresponding to the subject. RL (Read security level) is the highest sec level from which the subject is allowed to read. WL is the lowest sec level to which the subject is allowed to write. AIL (Absolute int. level) is assigned upon its creation and fixed for the whole life of the subject. It is the int level of the user corresponding to the subject. RIL: Lowest int level from which the subject is allowed to read. WIL: Highest int level to which the subject is allowed to write. For each s: WL(s) & AL(s) & RL(s) RIL(s) & AIL(s) & WIL(s) A subject for which al least one inequality is strictly satisfied (WL(s) < AL (s) < RL (s) or RIL(s) < AIL(s) < WIL(s)) is said to be trusted. A subject can be trusted from the viewpoint of secrecy, integrity, or both. ubjects for which the 4 relations are satisfied by = are said to be untrusted. 24

25 Objects and their classification Objects: Any data storage entity in the system. Each object is assigned 3 sec levels and 3 int levels: AL (Absolute sec level) is the sec level of the data contained in the object; fixed for the whole life of the object. ML (Migration sec level), is the highest sec level to which the data in the object may flow. CL (Corruption sec level), is the lowest sec level from which data may flow into the object. AIL (Absolute int level), is the int level of the data in the object. Fixed during the object life. MIL (Migration int level), is the lowest int level to which data in the object may flow. CIL (Corruption int level), is the highest int level from which data may flow into the object. For each o: CL(o) & AL (o) & ML (o) MIL(o) & AIL(o) & CIL(o) 25

26 Axioms Connection should be established when a subject wishes to transfer data between two objects. Connection between O1 and O2: O1 O2 All explicit connections are uni-directional. ubjects can cause data flow by making the appropriate system call. Once a connection is established, no more constraints are forced. Figure 2.19 in the next slide 26

27 Axioms Migration property: The migration level of O2 (to which it is written) must be as restrictive as those of O1 (from which it is read) ML (o1) ML (o2) MIL (o1) & MIL (o2) If this property is not satisfied, data in O1 may migrated improperly through O2. ML(O2) AL(O3) ML(O1) AL(O2) AL(O1) 27

28 Corruption property The corruption level of O1 (from which it is read) must be as restrictive as those of O2 (to which it is written) CL (o1) CL (o2) CIL (o1) & CIL (o2) If this property is not satisfied, data which is not allowed to flow into o2 would be able to flow through the mediation of O1. AL(O2) AL(O1) CL(O2) AL(O3) CL(O1) 28

29 Axioms - ecurity property The subject establishing a connection must have read access to the object O1 and write access to O2. The RL of must be of the AL of O1. The WL of must be the AL of O2. RL () AL (o1) WL () & AL (o2) This property corresponds to the No-Read-up and No-Write-Down of BLP Axioms - Integrity property The subject establishing a connection must have read access to the object O1 and write access to O2. The RIL of must be & of the AIL of O1. The WIL of must be the AIL of O2. RIL () & AIL (o2) WIL () AIL (o2) This property corresponds to the No-Read-Down and No-Write-Up of Biba. 29

30 Write/Corruption property: AL () CL (o2) AIL () & CIL (o2) Read/Migration property: AL () & ML (o1) AIL () MIL (o1) 30

31 The ea View model Proposed by Dorothy Denning, 1987 Ecure data VIEW model Aim: Protection of relational database systems. Formulated in two layers: 1- MAC (mandatory Access control): corresponds to a reference monitor enforces MAC. 2- Trusted computing base (TCB): defines the concept of multi-level relations, supports discretionary controls for multi-level relations and views. TCB information is stored in objects mediated by the MAC ref monitor. The ea View model (cont.) The MAC model provides a formal statement of ea View mandatory policy stating that no user has access to data unless it has the requisite secrecy and integrity clearance for the info. The ea View mandatory policy is formalized in terms of subjects, objects, and access classes. Access classes: two components secrecy class (similar to Bell LaPadula s security class) integrity class (similar to Biba model) Objects: information containers ubjects: processes acting on behalf of users Access modes: Read, Write and Execute 31

32 The ea View model (cont.) Access classes form a lattice based on the dominates () relationship. An access class C 1 dominates access class C 2 if and only if: the secrecy component of C 1 dominates the secrecy component of C 2 and the integrity component of C 1 is dominated by the integrity component of C 2 C 1 U C 2 iff C 1.ecrecy C 2. ecrecy && C 1.Integrity H C 2.Integrity The ea View model (cont.) Examples: ((T, Nato), (I, Nato)) U ((, Nato), (VI, Nato)) The access classes ((T, Nato), (VI, Nato)) and ((, Nato), (I, Nato)) are incomparable. Objects: containers of data, have unique id and unique access class, fixed during its life. Objects protected by MAC are single-level files. ubjects are processes acting on behalf of users. Each user is assigned a range of secrecy and integrity classes in which he is permitted to operate. 32

33 The ea View model (cont.) Each user is assigned minimum secrecy and integrity classes denoted by minsecrecy and minintegrity. There are also standard maxsecrecy and maxintegrity. The pair (minsecrecy, maxintegrity) is called the writeclass of the subject. The pair (maxsecrecy, minintegrity) is called the readclass of the subject. For each subject the readclass must dominate the writeclass. A subject is trusted if his/her readclass strictly dominates the writeclass. The meaning of trusted in terms of secrecy and integrity?? Untrusted subjects have equal readclass and writeclass. The ea View model- MAC Axioms (1) Read property: A subject s can read an object o only if its read class dominates the access class of the object. Formally, s can read o only if readclass (s) access class (o). i.e. maxsecrecy component of the subject secrecy class of the object and the minintegrity component of the subject H the integrity class of the object. In fact: NO READ UP secrecy principle + NO-READ-DOWN of the strict integrity policy 33

34 The ea View model- MAC Axioms (2) Write property: A subject s can write an object o only if its write class is dominated by the access class of the object. Formally, s can write o only if writeclass (s) accessclass (o). i.e. minsecrecy component of the subject H the security class of the object and the maxintegrity component of the subject the integrity class of the object. In fact: NO WRITE DOWN secrecy policy + NO-WRITE-UP of the strict integrity policy. The ea View model- MAC Axioms (3) Execute property: A subject s can execute an object o only if its maxintegrity is H the integrity class of the object, and its maxsecrecy is U the secrecy class of the object. Biba model restricts reading of lower classes, which is too restrictive for execution. o in this model, execution is distinguished from read; allowing trusted subjects to read data of lower integrity. The above property means trusted subjects can read data of lesser integrity level than their maxintegrity but their execute access is limited to programs of greater or equal integrity. 34

35 The ea View model (cont.) The combined property of trusted subjects The ea View model (cont.) Trusted Computing base, TCB model: The trusted computing base model defines multilevel relations and formulates discretionary security policy. Classification can be assigned to single elements of a relation (attribute s value). Multilevel relations: A multilevel relation is defined as any relation where there exist classification attributes C i for each data attribute Ai and a classification attribute for each tuple. Formally, a multilevel relation is represented by a schema R(A 1, C 1,, A n, C n, T c ). A multilevel relation is single-level if all attributes are single level and of the same class. 35

36 Each tuple has the form <a 1 c 1,,a k c k,t>, saying the value and classification for each attribute as well as the tuple. t indicates the tuple access class. For simplicity, only the secrecy levels are considered. example: Name C Name Dept C Dept alary C alary TC Babak d1 10K Ali d2 30K T T ara T d2 T 30K T T Instances For any given access class C, the instance contains all elements whose classification is dominated by C. -Instance Name C Name Dept C Dept alary C alary TC Babak d1 10K Ali d2-36

37 The ea View model (cont.) The classification of objects in the ea View model must satisfy the following properties: 1. Database class integrity: The access class of a relation schema must dominate the access class of the name of the database to which it belongs. 2. Visible data property: The access class of the relation schema must be dominated by the access class of the lowest data that can be stored in the relation. The greatest lower bound of the range of access classes specified for an attribute must dominate the access class of the relation schema. The ea View model (cont.) 3. View Class integrity: The access class of a view definition must dominate the access class of any relation or view named in the view definition. 37

38 Properties on Multilevel Relations Mutilevel entity integrity Let AK be the set of attributes forming the primary key of R, all attributes in AK have the same classification within any given tuple in R, and this is dominated by the value of each classification attribute other than AK. No null value in the elements of the primary key attributes. If this constraint is not satisfied, some instances of the relation would have undefined key attributes Multilevel referential integrity No tuple in a relation have a non-null secondary key unless a tuple exists in the referenced relation with the corresponding primary key. Within a tuple, the access class of the secondary key elements must be the same and must dominate the access class of the primary key elements in the tuple referenced. All references will be downward in access class. 38

39 Polyinstantiation Polyinstantiation refers to the simultaneous existence of multiple data objects with the same name and distinguished through their access class. Polyinstantiated relations: relations with the identical relation name but different access classes. Polyinstantiated tuples (entity polyinstantiation): tuples with the same primary key but different access classes associated to the primary key. Polyinstantiated elements (attribute polyinstantiation): elements of an attribute having different access classes, associated with the same primary key and key class. Polyinstantiated tuple / Polyinstantiated element Name C Name Dept C Dept alary C alary TC Babak d1 10K Ali d2 30K T T ara ara T d2 d1 T 30K 10k T T Insert another ara record by a -subject Name C Name Dept C Dept alary C alary TC Babak d1 10K Ali Ali d2 d2 30K 20k T T ara T d2 T 30K T T Update of the Ali record by a -subject 39

40 Polyinstantiation integrity The main point in creation of the polyinstantiated components is the INERT command! New tuples must be inserted without the notification of existence error (existence of a tuple with different sec class). Polyinstantiation is regulated by: - R with AK as primary key and CK as the key class, for each Ai not in AK: AK, CK, Ci Ai and also the following multivalue dependency: AK, CK A,C Access to Multilevel Relations How write (insert and update) operations are dealt in the model. For read ops, subjects access data at their level or below. For write: 1-The subject clearance H by (or incomparable with) the access level of data. Happens when a subject needs to insert new data in a relation, but data with the same name exists at the higher class. insertion must be accepted. a polyinstantiated tuple is inserted when an invisible tuple of the same primary key exists. a polyinstantiated element araises whenever a subject updates what appears to be null (but indeed hidden due to access level). 40

41 2-The subject clearance dominates the access level of data; either - the operation can be denied and the conflict is notified, or - operation is executed; polyinstantiation is araised. A polyinstantiated tuple arises whenever a subject inserts a tuple having the same existing PK at the lower sec class A polyinstantiated element arises whenever a subject updates an attribute having the lower sec class Execute some operation on this table! Name C Name Dept C Dept alary C alary TC Babak d1 10K Ali d2 30K T T ara ara T d2 d1 T 30K 10k T T 41

42 Discretionary ecurity Policy Allows users to specify which users are authorized or denied for specific modes of access to particular database objects. Negative authorization is not possible, but a null mode is used to signify negation. The ea View model (cont.) Different Access modes are specified according to the different types of the considered object: 1. Database access modes: Null: To deny any access on a database; List: To obtain the names and schemas of the multilevel relations belonging to a database; Create-mretlation: To create a multilevel relation in a database; Delete-db: To drop a database Grant: to grant other users the authorization for any access mode (other than grant and give-grant) on a DB. Give-grant: to grant other users the authorization for any access mode (including grant and give-grant) on a DB. 42

43 The ea View model (cont.) Access modes (cont.) 2. Discretionary access modes (applicable to individual relations and views) Null: To deny any access to a relation; elect: To retrieve tuples from a relation; Insert: To insert tuples in a relation Update (i): To modify the ith data attribute of a relation; Delete-tuple: To delete tuples from a relation; Create-view: To create view on top of a relation Delete mrelation: To drop a relation The ea View model (cont.) Discretionary access modes (cont.): Reference: To refer to a relation; this is necessary in order to access views defined on top of the relation Grant: To grant other users the authorizations for any access mode (other than grant and give grant) on a relation Give-grant: To grant other users the authorizations for any access mode (including grant and give grant) on a relation 43

44 The ea View model (cont.) Access modes (cont.) 3. MAC objects (low-level objects of the MAC model where info is contained) access modes Read: To read an object Write: To write an object Null: To deny any access on an object Grant: To grant other users the authorizations for any access mode (other than grant and give grant) on an object Give-grant: To grant other users the authorizations for any access mode (including grant and give grant) The ea View model (cont.) Access control rules: 1. If a user is explicitly denied access to an object, this denial takes precedence over any authorization this user might own either personally or as a member of a group. 2. If a user does not personally own any negative authorization on an object but does personally own the positive authorization for some access modes on the object, then he or she is granted only these accesses, and no other accesses owned by the groups to which he or she belongs 44

45 The ea View model (cont.) Access control rules (cont.): 3. If nothing has been specified for a user on object, and if the user is a member of a group that is not denied access to this object, then he or she holds the access rights specified for the group. 45

46 The Jajodia & andhu model Jajodia & andhu (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: chema and Multiple Instances based on each access class. A multilevel relation consists of two parts: (1) A state-independent multilevel relation scheme R (A 1, C 1,, C n, TC), where each Ai is a data attribute defined over domain D i, each C i is a classification attribute for Ai, and TC is the tuple class attribute. The domain of C i 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)]. 46

47 The Jajodia & andhu model (cont.) (2) A collection of state-dependant relation instances R c (A 1, C 1,, A n, C n, 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,, a n, c n, tc) where each element ai is either a value of domain D i or null, each c i is a value of the specified range and smaller than tc, that is, c i [ L i, H i ] c i tc, and tc is the least upper bound of the classes of the attribute in the tuple: that is, tc = lub { c i : i=1,,n} The Jajodia & andhu model (cont.) Example of a multilevel relation Employee 47

48 The Jajodia & andhu model (cont.) Instances at the -level and T-level of the Employee relation The Jajodia & andhu 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 R c of R and t R c (1) A i AK t[a i ] #null (2) A i, A j AK t[c i ]=t[c j ], ie. AK is uniformly classified, and (3) A i AK t[c i ] t[c AK ] (where C AK is defined as the classification of the apparent key) 48

49 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)! ubsumtion relationship: t subsumes s, if for every attribute Ai: t [Ai, Ci] = s [Ai, Ci] or t[ai]!= Null and s [Ai] == Null. The Jajodia & andhu model (cont.) Properties of the model (cont.): (2) Null integrity: A mutilevel relation R satisfies null integrity if and only if for each instance R c of R both the following conditions are satisfied: (1) For all t R c, t[a i ] = null t[c i ] = t[c AK ]: that is, null values are classified at the level of the key. (2) R c 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. 49

50 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 = (R c, c ), where the filter function produces the c - instance R c from R c as follows: (1) For every tuple t R c such that t[c AK ] c, there is a tuple t Rc, with t [AK,C AK ]=t[ak,c AK ] and for Ai AK t [ A i, C i ] = t[ A i, C i ] if t [Ci] c, && = <null, C AK > otherwise 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. 50

51 (4) Polyinstantiation integrity property: A multilevel relation R satisfies Polyinstantiation integrity if, and only if, for every R c, for all A i : (AK, C AK, C i ) A i. 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. Access to Multilevel relations: Deal with the write operations (Insert, Update, Delete) Read is processed through the Read-Down principle. 51

52 The Jajodia & andhu model (cont.) Insert operation: The insert operation, from a c-user, has the following from: INERT INTO R c [A i [, A j ] )] VALUE (a i [, a j ] ) 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 R c : u [AK] t[ak] If the conditions are satisfied, the tuple is inserted into R c and all the instances R c >c The Jajodia & andhu model (cont.) Results of the operation INERT VALUE John, Dept2,20K on and T instances of Employee from T subject T Instance 52

53 The Jajodia & andhu model (cont.) Results of the operation INERT VALUE Bob, Dept2,20K on and T instances of Employee from T subject The Jajodia & andhu model (cont.) Update operation: An update operation from a c user has the following form: UPDATE R c ET Ai = i [, A j = j ] [WHERE P] Where each s i is a scalar expression, and p is a predicate expression which identifies those tuples in R c that are to be modified If the conditions are satisfied, the update is propagated into R c >c according to the minimum propagation delay policy: only those tuples which are needed to preserve the inter-instance property are inserted in R c >c 53

54 The Jajodia & andhu model (cont.) Results of the operation UPDATE salary = 30K WHERE Name = Ann on and T instances of Employee from T subject The Jajodia & andhu model (cont.) Result of the operation UPDATE Department= Dept1 WHERE Name = Ann and and T instances of Employee from T subject am 54

55 Delete Propagation of Delete to Rc >c A multilevel relation to illustrate multilevel security [ FIGURE 22.2 from ELMARI, 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 mith tuple. 55

56 The Jajodia & andhu model (cont.) ome 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. mith & Winslett model By: mith & 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 56

57 mith & 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. mith & Winslett model (cont.) Multilevel relations Unlike the ea View and the Jajodia models, the mith & 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,, A n, 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. 57

58 QUERY PERATION(mith/Winslett) Different strategies for execution based on belief level are specified: UPDATE R ET ATTR = value WHERE <predicate p> BELIEVED BY L =================== UPDATE EMPLOYEE ET ALARY = 30k WHERE ALARY = 20K BELIEVED BY Anyone Discussions on mandatory models Advantages: uitability 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. 58

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

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

61 Isolation Virtual Machine: simulating a computer system. JVM Analyzing all actions against leaking of info: ANDBOX A sandbox is an environment in which the actions of a process are restricted according to the security policy. E.g. JVM 61

62 Database ecurity 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 app development. Design methodology is required. In all phases of a DB design, sec issues should be considered: Analysis, Conceptual design, Detailed design, Implementation, test, maintenance. 62

63 ecure DBM design A set of mechanisms at the O and DBM level. ome of the mechanisms can be used from the O side. ecurity can not be added as an extension! Difference between O and DBM concerning security: Object granularity: file vs relation, row, tuple, emantic correlations among data in DBM Metadata, which exists in DBM ensitivity of metadata, should be protected. No metadata in O. Logical and physical objects: objects in O are physical and in DBM are logical. file vs view Multiple data types: multiple data types and multiple access modes (statistical mode, administrative mode). tatic & dynamic objects: relations and views. pecial protection is needed for dynamic objects. Multi-level transactions: transactions involving different sec levels. Data life cycle. In DBM, data has a long life cycle. Protection must be assured throughout the whole lifetime of the data. 63

64 ec. mechanisms in DBM The main sec mechanisms that a DBM should provide: Different degrees of granularity of access: relations, tuples, database, Different access modes, read is differentiated from write. Different types of access controls: Name-dependent Data-dependent: content. Context-dependent: date, time,. History-dependent Result-dependent Dynamic authorization: DBM should support the modification of users authorizations while the DB is operational. Multi-level protection: ecurity 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. 64

65 No back doors, access only through DBM! Uniformity of mechanisms Reasonable performance Basic principles of Information Integrity Well-formed transactions instead of arbitrary procedures Authenticated users: change should be executed only by auth users. Least privilege od Continuity of operation, through replication Reconstruction of events, through before-image or after-image 65

66 ystem R Authorization Model The very first DBM, developed by IBM. Tables, as objects to be protected. Base tables or views ubjects are the users who access the DB. Access modes applicable to the DB tables: Read Insert Delete Update Drop: delete an entire table 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. 66

67 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. Existence of the grantor and the time of grant is the way we revoke, described later. The grant command in QL: 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> 67

68 Revoke Mechanism ystem 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 A 10 B 30 D 40 E 70 G 20 C F B has granted a privilege to D, who has passed it to E, who has passed it to G 10 B A D B revokes D s privilege C F 68

69 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 > What should be done?? Defining the view select * from T where a1>1000 and then grant B the read authorization on the view 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. 69

70 Implementation of the model Two relations named: YAUTH and YCOLAUTH YAUTH 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 ome values Grantopt: the Grant operation. Fig 4.2 corresponding to Figure 4.1 (a) In the revised version, if two similar grants are happened, two records are inserted with different timestamps. YCOLAUTH: If there is specified some in the YAUTH update column, a tuple is needed for each column UserId Table Column Grantor Grantopt 70

71 Extension of the model 1982 by Wilms and Linsday to consider group management. et of users in a group. Groups may overlap. Applied in ystem R*, the distributed DBM. Another extension: having cascadable revoke or non-cascadable revoke! Non-cascade revoke A 10 B 30 D 40 E 70 G 20 C F B has granted a privilege to D, who has passed it to E, who has passed it to G A 10 B C D E F G B revokes D s privilege 71

72 Main features of a ecure DB Arch. DBMs operate according to two possible modes: ystem-high or Multilevel In ystem-high DBMs, 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 DBMs. Multi-level mode Based on using trusted and untrusted DBMs. Trusted ubject Arch Using a trusted DBM and a trusted O From scratch or extension of the security features. Woods Hole Archs, were an untrusted DBM is used with an additional trusted filter Integrity Lock Kernelized Replicated 72

73 Architecture Integrity Lock Research prototype Mitre Commercial DBM TRUDATA Kernelized eaview Oracle Replicated NRL Trusted ubjet A1 ecure DBM ybase Informix Ingres Oracle DEC Trusted ubject Arch Figure in the next slide. A set of untrusted front ends is used to interface with different clearances (Low and High). TDBM and TO form a single TCB (Trusted Computing Base) DBM is responsible for multi-level protection of DB objects. High level dominates the low-level. DBM subjects and objects are assigned DBM labels and so trusted and exempted from O mandatory controls. ybase adopts this solution by assigning tuplelevel labels. 73

74 High user low user Untrusted Front end Untrusted Front end Trusted DBM Trusted O Database (DBM & NON-DBM DATA) Woods Hole Archs General arch is fig 4.5 A set of untrusted font ends It then interface with a monitor (trusted front end) which cannot be bypassed. It interfaces an untrusted back end. 74

75 High user low user Untrusted Front end Untrusted Front end Trusted front end (reference monitor) UnTrusted DBM Database 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 DBM. TFE is responsible for enforcing sec functions and multilevel protection. tamp contains sec label and other relevant control data. tamps 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 DBM Figure