Transcript Information Security Databases and (Inter)Networks

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.
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.
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.
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.
Next-generation databases
• Object-oriented databases:
– Object and object identifier: to represent realworld 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.
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 BellLaPadula mandatory security model.
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).
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)
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)
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.
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 contentdependent authorization. (e.g. “self_salary”
derived from “salary”, for people allowed to
only view their own salary)
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.
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.
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)
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.
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 objectoriented systems. This makes the verification
of the correctness of security provisions
difficult.