Set 5, OODB Security - MAC Sylvia Osborn CS96161Set 5, MAC for OODB

First look at SORION an MLS version of Orion, proposed by B. Thuraisingham in Bhavani M. Thuraisingham: Mandatory Security in Object-Oriented Database Systems. OOPSLA 1989: Bhavani M. Thuraisingham: Mandatory Security in Object-Oriented Database Systems. OOPSLA 1989: Basic Assumption: there exists a security lattice which is partially ordered Terms: CS9616 Set 5, MAC for OODB 2 Security Terms (for MAC)OO Terms object subjectuser access modemethod security level or class part or componentinstance variable class of object

Objects in the security sense include class instances, i.e. objects atomic objects like integers, reals, strings etc. complex literals (structure with no object ID) class definitions instance variables/attribute names Methods: regard as a mapping m: C 1 x C 2 x... C n → C C i are underlying security classes of the parameters of the methods C is the class of the result, i.e. the class of the object on which the method is defined. the method may cause some side effects on the object upon which it acts CS9616 Set 5, MAC for OODB 3

Model of a method m  denoted by M(m, L)  defined as the set of partial functions M(C 1, L) x M(C 2, L) x... x M(C n, L) → M(C, L)  where M(C i, L) denotes the set of all instances of class C i with security level less than or equal to L. Subject  any user of the system  each subject is assigned a security level Access Modes  read, write, execute CS9616 Set 5, MAC for OODB 4

Security Properties for Objects P1: every object has a security label, denoted Level(o). P2: If o is a basic (atomic) object (integer, string, Boolean or real), then the Level(o) is system-low. P3: The security level of a name must dominate the security level of its value. (This could apply to attributes, or just object names, or whatever.) P4: If o is a set object {o 1, o 2,... o n } then Level(o) ≥ lub(Level(o 1 ), Level(o 2 ),... Level(o n )) i.e. the security level of a set object must dominate the security levels of its members. If there were other data structures like bags, lists or arrays, a similar property would have to be defined for them. P5: The security levels of the attribute names of an object are the same as that of the object. This model does not allow for multiple security levels within a single object instance. CS9616 Set 5, MAC for OODB 5

Classes P6: All classes (class definitions) have a security level. P7: The security levels of the instances of a class must dominate the level of the class. P8: Anyone who can read the name of a class should also be able to read the attribute names of the class. e.g., possible to have a class definition: Emp (Name : string, SIN : string, Age : integer) where the name Emp, and the attribute names: Name, SIN and Age are all classified as Confidential (note that string and integer values will be Unclassified) and have instances: Bob: ( Bob Jones, , 45) : Secret Ann: (Jane Jones, , 50) : Top Secret Jim: (Jim Jones, , 29): Confidential but no unclassified instances of Emp CS9616 Set 5, MAC for OODB 6

Subclasses P9: The security level of a subclass must dominate (≥) the level of the superclass. This allows inheritance to take place. Also consistent with the idea that the members of the subclass are more specialized objects. P10: The instance variables of a subclass (whether inherited or newly defined) must have the same security level as that of the whole subclass (only single-level class definitions are allowed). e.g. declare a subclass of Emp: Astronauts, and the Astronauts class is Secret, and has the additional attribute: mission Then, all 4 instance variables of the Astronaut class are classified as Secret, and this class can have Secret or Top Secret instances. CS9616 Set 5, MAC for OODB 7

Methods P11: All methods have a security level. P12: If a method m is defined on C 1 x C 2 x... x C n, and its range is C, then Level(m) ≥ lub(Level(C 1 ), Level(C 2 ),... Level(C n ), Level(C)) P13: Given the definition for the model of a method, method m 1 is said to be a submethod of m 2 if M(m 1, L) is a subset of M(m 2, L), for all security levels L. P14: if C 1 is a subclass of C 2, and m 2 is a method of C 2, then there is a method m 1 of C 1, such that m 1 is a submethod of m 2, by inheritance of methods. The following condition must also hold: Level(m 1 ) = lub(Level(m 2 ), Level(C 1 )) (Note that this doesn't say anything about the method name.) CS9616 Set 5, MAC for OODB 8

CS4411/9538Set 4: Data Modelling Issues9 Aside on Multiple Inheritance when there is multiple inheritance, the class hierarchy is not a tree, but rather an acyclic directed graph. assume inheritance goes down the page: a subclass with two or more superclasses inherits all attributes and operations from all its superclasses Name, Address and Phone are inherited from 2 superclasses. This gives rise to a possible Name Conflict

CS4411/9538Set 4: Data Modelling Issues10 Dealing with Name Conflicts 1.Insist that there must be a common superclass (like Person) from which these attributes are inherited. 2.Disallow it altogether. This forces the programmer to rename one of the attributes in the superclass. 3.Establish an order for the superclasses and use that order to give priority to one of the superclasses. If the class ordering is Athletes before Students, then the name and address from Athletes is what is inherited, with syntax like: Athletes, Students (sub)class StudentAthletes...

CS4411/9538Set 4: Data Modelling Issues11 Dealing with Name Conflicts Use the above method and then allow the order to be changed on an attribute by attribute basis, during schema modification 5.Renaming: system appends the superclass name to the inherited attributes and inherits both

Multiple Inheritance P15: Let C be a subclass of C 1, C 2,... C n. Let attribute V be associated with C 1, C 2,... C n. C will inherit the attribute associated with class C j (1 ≤ j ≤ n) such that Level(C j ) dominates the levels of the remaining classes. If there is more than one such C j, then some a priori rule should be enforced to resolve the conflict. i.e. security considerations may have to take precedence over data modeling considerations. P16: Let C be a subclass of C 1, C 2,... C n. Let method m be associated with C 1, C 2,... C n. C will inherit the method associated with class C j (1 ≤ j ≤ n) such that Level(C j ) dominates the levels of the remaining classes. If there are more than one such C j, then some a priori rule should be enforced to resolve the conflict. CS9616 Set 5, MAC for OODB 12

Tuple-Like Structures P17: If class C is an aggregate whose parts are drawn from classes C 1, C 2,... C n, then Level(C) ≥ lub(Level(C 1 ), Level(C 2 ),... Level(C n )) Note that this deals with the level of the class definition. P18: For the above class C, the levels of an instance o, whose instance variables have values o 1, o 2,... o n, corresponding to C 1, C 2,... C n, Level(o) ≥ lub(Level(o 1 ), Level(o 2 ),... Level(o n )) This is consistent with atomic objects being classified at system low. Note that level(o i ) ≥ level(C i ), but level(C i ) ≤ level(C) ≤ level(o) CS9616 Set 5, MAC for OODB 13

An Example Class Employee: Secret (Name: String, Address: String, Salary: Sal, DateOfBirth: date) date: User-defined (object) type: Classified Sal: User-defined (object) type: Secret What do P2, P3, P7, P17 and P18 say? Method RaiseSalary (Date:date, Salary:Sal) : Employee; Employee subclass Astronaut : Top Secret (Mission : string) What happens to RaiseSalary in Astronaut? CS9616 Set 5, MAC for OODB 14

Security Policy for SORION 1. Subjects and objects (both in the security sense and in the OO sense) must all be assigned security levels. 2. A subject can read an object if the subject's security level dominates the level of the object. 3. A subject has write access to an object if the subject's security level equals the level of the object. 4. A subject can execute a method if the subject's security level dominates both the security level of the method and of the type on which the method is defined. CS9616 Set 5, MAC for OODB 15

Security Policy for SORION 5. A method executes at the security level of the subject who initiated the execution. 6. During the execution of method m 1, if another method m 2 has to be executed, then m 2 can be executed only if the execution level of m 1 dominates both the security level of m 2 and the security level of the type on which m 2 is defined. 7. If a new object has to be created as a result of executing a method, the object is created at the security level of the subject who initiated the execution of the method. Does this allow write down? CS9616 Set 5, MAC for OODB 16

The Millen-Lunt Model 1 Objects: the security objects correspond to the objects of the OO model (including classes). All objects must be single-level. Each object has a single security level assigned to it. Properties of an object (i.e. its attributes and methods) do not have a security level different from that of the object. Objects are created using a method defined in the root class of the object class hierarchy. A subject creates an object by sending a predefined message, called create, to the class of which the new object is to be an instance. 1 from Millen, J.K.; Lunt, T.F.; Research in Security and Privacy, Proceedings., 1992 IEEE Computer Society Symposium on, 4-6 May 1992 Page(s): from Millen, J.K.; Lunt, T.F.; Research in Security and Privacy, Proceedings., 1992 IEEE Computer Society Symposium on, 4-6 May 1992 Page(s): CS9616 Set 5, MAC for OODB 17

Subjects in Millen-Lunt A subject is an active entity that executes methods upon reception of messages, and can also send messages. i.e. each subject corresponds to a method execution. Each time an object receives a message, a new subject is created. The object is referred to as the home of the subject. the subject that sent the message is referred to as the invoker of the subject created to handle the message. the subject created to handle a message is deleted upon completion of the method. the subject is assigned a security level equal to the least upper bound of the levels of the invoker subject and the home object. a subject may change its security level, but only to upgrade itself (changing to a lower level would create a covert channel.) CS9616 Set 5, MAC for OODB 18

Access Modes in Millen-Lunt The following predefined system methods are defined: Create to create new instances of an object Delete to delete instances of an object Addmessage to add methods to an object Getvar to read attributes of an object Setvar to write attributes of an object CS9616 Set 5, MAC for OODB 19

Properties of the Millen-Lunt Model Hierarchy property: The level of an object must dominate that of its class object. This allows instances to be able to use the instance variables and methods of their class. Subject level property: The security level of a subject must dominate the level of the invoking subject, and it must also dominate the level of its home object. A subject is assigned a security level which is the least upper bound of the level of its home object and the invoking subject. This satisfies the subject level property. Object locality property: A subject can execute methods and read or write variables only in its home object. A subject can execute methods of another object by sending the object a message. This creates a new subject. This property is consistent with encapsulation in OO systems. CS9616 Set 5, MAC for OODB 20

More Properties for Millen-Lunt *-property: A subject may write into its home object only if its security level is equal to that of the object. It is possible for the subject's level to be higher than that of its home object, but such a subject would not be allowed to write to the home object because this would create a “write down” situation. Return value property: A subject can send a return value to its invoking subject only if it is at the same security level as the invoking subject. This prevents information going from high to low. A subject may generate a result which the invoker cannot be allowed to receive. Object creation property: The security level of a newly created object must dominate the level of the subject that requested the creation. If not, subject could write down. CS9616 Set 5, MAC for OODB 21

Polyinstantiation In both of these models, what if a high subject created an employee object and a low subject created an employee object with the same attribute values? Would they have the same object ID? Are they really the same object? If there is an independent notion of value-based keys in the system, then having the same name and empno might lead you to believe they are the same object, with two different versions. So, there is a (very small) place for polyinstantiation in OODB, but only if there is some way to know that you are talking about the “same” object. CS9616 Set 5, MAC for OODB 22

Multilevel Objects both of these models talk about how to represent multi-level objects if you really want to. suppose you want an Employee with Name and SIN unclassified, and Salary secret. Can create the following two classes: U-Employee -- Unclassified ( Name : string, SIN : string ) S-Employee -- Secret ( Employee : U-Employee, Salary : integer) with this construction, all objects that are stored are single-level. a drawback of this approach is that classes must be redefined from the underlying database, and methods may have to be rewritten. CS9616 Set 5, MAC for OODB 23

Potential Problems Garbage collection: Suppose a low object is deleted. Some of its (contained object) parts may not be deleted because they are a value for a higher level object. The low user might be able to see this. This creates a covert channel, because it makes the low user aware of some high object. To achieve high levels of certification according to the orange book, formal methods and formal definitions must be used. One problem with object-oriented databases is that there is no formal model of a database which is agreed on. This means it is hard to formalize the security aspects of the model, and achieve B1 etc. compliance. CS9616 Set 5, MAC for OODB 24