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