Next-generation databases

1. Next-generation databases • Active databases: when a particular event occurs and given conditions are satisfied then some actions are executed. An active database contains a knowledge base of such rules. • Rules can be used to maintain integrity constraints. • Rules can be used to maintain derived data. (such data correspond to views) • The execution of rules can create a threat. • The rules themselves need protection.

2. Starbust • Developed at IBM Almaden Research Center. • Procedure calls can be attached to tuple-level operations; this leads to a tuple-oriented database rule system. • An event queue allows deferring the execution of procedures. • Table functions allow the registration of a function name, a parameter specification, a table and a procedure to produce tuples. The function name is used in the SQL FROM clause as if it were a “real” table.

3. Starbust (cont.) • New authorizations: (these rights can be granted and revoked) • Control: the right of the creator of a rule. Control is needed to grant/revoke rights. • Alter: the right to modify a rule. • Activate/deactivate: to activate or deactivate a rule. To create a rule on a relation one needs attach and read rights on the relation.

4. Multi Level Secure relational model • Integrated with active database by Smith and Winslett. • Gives explicit security classifications to rules and events via multilevel secure relations for each. • Rule descriptions and events are expressed in tuples with security labels. • User-definable active components conform to the mandatory policies for subjects.

5. Next-generation databases • Object-oriented databases: • Object and object identifier: to represent real-world entities and address the representation. • Attributes and methods: objects have data attributes and operations on the object. • Class: abstraction mechanism for objects with the same structure. • Complex objects: the value of an attribute can itself be an object. • Inheritance: specialization, subclassing. • Information hiding: access to data only through method calls.

6. Security in object-oriented DBMS • Most OODBMS do not provide (discretionary) security controls that are comparable to those of relational DBMS. (exceptions: Orion and Iris) • Through “multiple interfaces” one can enforce some kind of view mechanism without compromising performance. • Message filters are used to enforce the Bell-LaPadula mandatory security model.

7. The ORION authorization model • Subjects: users are identified with roles. Roles form a lattice. (acyclic graph with partial ordering relationship). • Objects: to be protected are databases, classes, set of instances (set of objects), object, attributes and values, methods. • Access modes:write, read (means execute for methods), generate (to create instances of an object class), read_definition (to read the definition of an object class).

8. The ORION authorization model • Strong authorization base: groups authorizations (positive and negative) that cannot be overwritten. (no redundancy is allowed) • Weak authorization base: groups authorizations (positive and negative) that can be overwritten. (redundancy is allowed)

9. The ORION authorization model • Rules for deriving implicit authorizations: implicit authorizations are derived from explicit authorizations defined by users. • Inheritance: two choices • authorizations do not propagate to subclass. (subclass may be more sensitive) (default in ORION) • authorizations propagated to subclasses. (creator of a class must be able to update and read instances of subclasses) (user option in ORION)

10. The ORION authorization model • Composite objects: considered as an authorization unit. • This is essential for acceptable performance. • Authorization only holds for objects and components, not the whole class for the components. • Versions: • generic instance: access to generic instance implies same access to all versions (and vice versa). • versions: access to just one version is possible.

11. The Iris authorization model • Takes advantage of the possibility to use encapsulation: authorization is based on the execution of methods. • The user who creates a function is owner of the function and can grant others authorization to call the function. • Derived functions are used to support content-dependent authorization. (e.g. “self_salary” derived from “salary”, for people allowed to only view their own salary)

12. The Iris authorization model • Generic functions allow polymorphism. A user authorized to call a generic function is also authorized to call the associated specific functions. • Guard functions for other functions define conditions that are tested before granting call permission of the function to which the guard is associated. • Proxy functions provide different implementations of specific functions for different users. They can be used to allow to check constraints for certain users.

13. Security shortcomings in OODBMS • Representation of real-world entities: Security classification may affect (hamper) the way in which real-world entities must be mapped into the underlying object schema. (e.g. only one authorization for whole complex objects) • Secure update and delete operations: Objects may reference objects with a different security level. E.g. if an object references a lower object and the lower object is deleted a dangling reference may result.

14. Security shortcomings in OODBMS • Polyinstantiation: A single object may have attributes with different values at different security levels. OODBMS do not support such objects. • Sanitization: It may be necessary to enforce methods that access high-level data but return data at a lower level. It is difficult to ensure that methods will not leak high information (i.e. that no covert channel will arise)

15. Security shortcomings in OODBMS • Access synchronization: High and low processes may need concurrent access of low information. The low processes cannot be informed of computation at higher levels. It is difficult to guarantee correct computation without revealing the existing of the high process. • Garbage collection: may introduce covert channels: if a low object is not collected because a high object references it, low users may infer the existence of the high object.

16. Security shortcomings in OODBMS • Identification of trusted components: The amount of trusted code necessary to perform computation securely should be kept minimal. Trusted code must be verified formally. • Formal model: There are no standard reference models for security in object-oriented systems. This makes the verification of the correctness of security provisions difficult.