You are hereMultilevel Security / MLS Polyinstantiation

MLS Polyinstantiation


The intent of Multilevel Security is to prevent unauthorized information flows to users who are not cleared to access the information. One covert way that illegal information flows may occur within non-secure systems is by exploiting unique object naming collisions between security domains. The value of a unique key within a row may easily be used to infer the existence of high-level key values by a low-level user not cleared to access the information..

 

Consider the following steps that may be performed within a non-secure DBMS to extract sensitive information. The diagram that follows corresponds to the following steps:

  1. A low-level table is created with a unique primary key.
  2. A high-level user inserts a value into the low-level table.
  3. A low-level user "fishes" for the value of the high-level key by attempting to insert various key values.
  4. When the low-level user receives an error message that says the row cannot be inserted because the unique key already exists; and, the low-level users verifies that no such key exists at a dominated level, then the low-level user knows the existence of the high-level key value.

This process may be incorporated into a computer program for quick retrieval of high-level information resulting in a high bandwidth covert channel.

 

Trusted RUBIX removes the potential for such illegal information flows through polyinstantiating DBMS objects that have unique names. This is explained later on this page.

 

Diagram Showing Illegal Information Flow of Systems with No Polyinstantiation

Trusted RUBIX employs polyinstantiation to eliminate potential illegal information flows that may occur due to naming collision. Polyinstantiation is the process of using duplicate resources or objects to remove conflicts between concurrent accesses.

 

In the case of primary key values, Trusted RUBIX creates a duplicate copy of the row containing the key value when the low-level user attempts an insert. Therefore, even though a duplicate key value exists at a high-level, the low-level insert succeeds, thereby hiding the existence of the high-level key. When the table is subsequently selected, each user will receives the copy of the row with the highest, dominated label. It is also possible to select all dominated, polyinstantiated rows from  a table.

 

The following diagram graphically demonstrates polyinstantiation of primary key values.

 

Diagram Showing Removal of the Information Flow with Polyinstantiation