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

Set 5, OODB Security - MAC

Sylvia Osborn

CS9616 1Set 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: 203-210

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 object

subject user

access mode method

security level or class

part or component instance 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: C1 x C2 x ... Cn → C

Ci 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


Model of a method m denoted by M(m, L) defined as the set of partial functions

M(C1, L) x M(C2, L) x ... x M(Cn, L) → M(C, L) where M(Ci, L) denotes the set of all instances

of class Ci 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


Security Properties for ObjectsP1: 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 {o1, o2, ... on}

then Level(o) ≥ lub(Level(o1), Level(o2), ... Level(on)) 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.


ClassesP6: 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, 999999999, 45) : Secret

Ann: (Jane Jones, 123456789, 50) : Top Secret

Jim: (Jim Jones, 987654321, 29): Confidential

but no unclassified instances of Emp


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


MethodsP11: All methods have a security level.

P12: If a method m is defined on C1 x C2 x ... x Cn, and its range is C, then

Level(m) ≥ lub(Level(C1), Level(C2), ... Level(Cn), Level(C))

P13: Given the definition for the model of a method, method m1 is said to be a submethod of m2 if M(m1, L) is a subset of M(m2, L), for all security levels L.

P14: if C1 is a subclass of C2, and m2 is a method of C2, then there is a method m1 of C1, such that m1 is a submethod of m2, by inheritance of methods.

The following condition must also hold:

Level(m1) = lub(Level(m2), Level(C1))

(Note that this doesn't say anything about the method name.)


CS4411/9538 Set 4: Data Modelling Issues 9

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


Dealing with Name Conflicts1. 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 ...


Dealing with Name Conflicts - 24. Use the above method and then allow the order to be changed on an

attribute by attribute basis, during schema modification5. Renaming: system appends the superclass name to the inherited

attributes and inherits both

Multiple InheritanceP15: Let C be a subclass of C1, C2, ... Cn.

Let attribute V be associated with C1, C2, ... Cn.

C will inherit the attribute associated with class Cj (1 ≤ j ≤ n) such that Level(Cj) dominates the levels of the remaining classes. If there is more than one such Cj, 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 C1, C2, ... Cn.

Let method m be associated with C1, C2, ... Cn.

C will inherit the method associated with class Cj (1 ≤ j ≤ n) such that Level(Cj) dominates the levels of the remaining classes. If there are more than one such Cj, then some a priori rule should be enforced to resolve the conflict.


Tuple-Like StructuresP17: If class C is an aggregate whose parts are drawn from classes C1, C2, ...

Cn, then

Level(C) ≥ lub(Level(C1), Level(C2), ... Level(Cn))

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 o1, o2, ... on, corresponding to C1, C2, ... Cn,

Level(o) ≥ lub(Level(o1), Level(o2), ... Level(on))

This is consistent with atomic objects being classified at system low.

Note that level(oi) ≥ level(Ci), but level(Ci) ≤ level(C) ≤ level(o)


An ExampleClass 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?


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.


Security Policy for SORION5. A method executes at the security level of the

subject who initiated the execution.6. During the execution of method m1, if another

method m2 has to be executed, then m2 can be executed only if the execution level of m1 dominates both the security level of m2 and the security level of the type on which m2 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?


The Millen-Lunt Model1

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, 1992. Proceedings., 1992 IEEE Computer Society Symposium on, 4-6 May 1992 Page(s):260 - 272


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


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


Properties of the Millen-Lunt ModelHierarchy 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.


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.


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.


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.


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.


Documents

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