Multilevel Security

Multilevel Security is a Mandatory Access Control (MAC) policy designed to control the flow of information between subjects based upon their trustworthiness. In general information is allowed to flow from less trustworthy subjects to more trustworthy subjects.

 

Subjects are assigned labels that represent their trustworthiness while objects are assigned labels that represent their sensitivity. These labels are used along with fixed Bell-La Padula rules to control operations. In general, Bell-La Padula rules allows subjects to read objects at lower labels and update objects at their label.

 

The simple and static nature of the Bell-La Padula rules provides the potential for a higher assurance of correctness as compared to more complex and dynamic security policy models.

 

Trusted RUBIX fully integrates the Multilevel Security policy into its DBMS, labeling all DBMS objects and controlling access to all SQL operations. In addition, Trusted RUBIX fully integrates with the Multilevel Security policy of the underlying operating system, providing coherent total-system security behavior.

 

For more detailed information about Trusted RUBIX Multilevel Security please see the links below or see the Trusted RUBIX MLS White Paper.

MLS Labels

Central to the Multilevel Security policy is the MLS label, also known as a level. Each subject (e.g., a DBMS session open on behalf of a user) and object (e.g., a DBMS row) is assigned an MLS label.

 

The MLS label assigned to a subject determines which operations the subject may perform. The subject label is also assigned to objects created by the subject. The MLS label assigned to an object determines which operations may be performed upon the object.

 

Generally, a subject may read an object if the subject's label dominates (is "higher" than) the object's label and may update an object if the subject's label equals the object's label.

 

MLS label's are composed of two distinct parts: the sensitivity (objects)/clearance (subjects) and the compartments. Compartments may also be known as categories.

 

The sensitivity/clearance component of a label represents the degree to which information is security-wise sensitive (object's only) and the user's trustworthiness (subjects only). It frequently takes on a string form like "Top Secret" or "Unclassified."

 

The compartments component of a label represents a user's "need to know." This usually refers to the information a user needs to operationally perform her duties. While they may be "cleared" or "trusted" to see other information, they have no operational need to see such data to perform their job responsibilities and, taking a conservative approach to security, the MLS policy denies them access.

 

Trusted RUBIX labels its DBMS objects with the same MLS labels used by the underlying operating system.

 

The following diagram gives sample MLS labels in Solaris 10 Trusted Extensions (TX) and SELinux formats. For SELinux, the MLS level is one of four components within its security context. The left-most part of each MLS label represents the sensitivity/clearance component while the right-most component represents the compartments.

 

In both cases the MLS label may be configured to have a user-friendly string representation. SELinux MLS label compartments may be specified as a comma separated list (e.g., c1, c5, c9) and as a range (e.g., c1.c3). Also note that a MLS label need not contain any compartments.

 

Sample MLS Labels

MLS Dominance Relationship

 

The Multilevel Security policy uses an ordering relationship between labels known as the dominance relationship. Intuitively, we think of a label that dominates another as being "higher" than the other. Similarly, we think of a label that is dominated by another as being "lower" than the other.  The dominance relationship is used to determine permitted operations and information flows.

 

The dominance relationship is determined by the ordering of the Sensitivity/Clearance component of the label and the intersection of the set of Compartments.

 

Sample Sensitivity/Clearance ordering are:

  • Top Secret > Secret > Confidential > Unclassified
  • s3 > s2 > s1 > s0

Sample Compartment intersections are:

  • The intersection of {AB} and {A} is {A}.
  • The intersection of {c1,c2} and {c1} is {c1}.
  • The intersection of {AB} and {C} is {}.

Formally, for label1 to dominate label2 both of the following must be true:

  • The sensitivity/clearance of label1 must be greater than or equal to the sensitivity/clearance of label2.
  • The intersection of the compartments of label1 and label2 must equal the compartments of label2.

Additionally:

  • Two labels are said to be equal if their sensitivity/clearance and set of compartments are exactly equal. Note that dominance includes equality.
  • One label is said to strictly dominate the other if it dominates the other but is not equal to the other.
  • Two labels are said to be incomparable if each label has at least one compartment that is not included in the other's set of compartments.

The dominance relationship will produce a partial ordering over all possible MLS labels, resulting in what is known as the MLS Security Lattice

MLS Information Flows

The Multilevel Security policy is concerned with the flow of information from one subject to another. There is a general requirement that information not flow from a "higher" level subject to a "lower" level subject. Flows of information are referred to as channels. For instance, a channel may not exist from a Top Secret user to an Unclassified user as this would allow an Unclassified user access to Top Secret information.

 

Within the Trusted RUBIX DBMS, all SQL operations are controlled to prevent improper information flows. So, for instance, a Confidential user may not SELECT a Top Secret row. Also, a Top Secret user may not UPDATE a Confidential row. A Top Secret user would be permitted to SELECT a Confidential row.

 

In addition to explicit information flow channels, such as selecting a row, Trusted RUBIX also eliminates some covert information flow channels. These are situations where a low level subject can infer information about a "high" level object or subject. Two primary areas where Trusted RUBIX removes illegal covert channels are within the concurrency control algorithm and through the use of polyinstantiation.

 

The following diagram shows the permitted and non-permitted information flows between a representative set of MLS labels. In general, information is allowed to flow from a source to a destination if the destination MLS label dominates (is higher than or equal to) the source MLS label. Note that no information flows are allowed between incomparable MLS labels, such as Top Secret: AB and Top Secret: C. Also note that not all permitted information flows are shown in the diagram, such as from Unclassified: A to Top Secret: AB.

 

MLS Information Flows

 

MLS Security Lattice

The following diagram shows the MLS Security Lattice for a representative set of MLS labels. The security lattice is a graphical representation of the dominance relationship between all labels in the system. For this example, the system has four sensitivity/clearance labels (TS>S>C>U) and two compartments (A and B). If a path exists from one node to a second node then the label associated with the first node strictly dominates the label associated with the second node. Information is permitted to flow from the first node to the second node.

 

Labels towards the top of the diagram have a higher sensitivity/clearance. Labels towards the right side of the diagram have more categories (need to know). The special label 'TS:AB' is referred to as System High because it dominates all other labels in the system and information may flow to it from any label in the system. The label 'U' is referred to as System Low because it is dominated by all labels in the system and information may flow from it to any other label on the system.

 

Trusted RUBIX uses the same MLS Security policy configuration, and thus security lattice, as the underlying operating system.

 

MLS Security Lattice Diagram

MLS Access Control Rules

All operations of the Trusted RUBIX DBMS have been integrated with the MLS Security policy, including all SQL operations. All DBMS objects (database, catalog, schema, view, table, index, row) are assigned an MLS label. The rules governing the general behavior of the MLS Security policy are:

  • Newly created objects are assigned the label of the creating subject.
  • A subject may read an object if the subject's label dominates the object's label.
  • A subject may update an object if the subject's label is equal to the object's label.
  • A subject may create a child object within a parent object (e.g., a row within a table or a table within a schema) if the subject's label dominates the parent object. The child will be assigned the label of the creating subject.

The following table enumerates the MLS access control rules for each SQL operation.

SQL Statement

MLS Access Control Rules

MLS Outcome

ALTER TABLE
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session  = table
Session  = table referenced by a foreign key
Table sensitivity label is unchanged.
CONNECT
Session >= database
The session sensitivity label for the connecting user is assigned from the label of the operating system connection (e.g., socket label)
CREATE CATALOG
Session >= database
New object labeled with the session sensitivity label.
CREATE DATABASE
Any Sensitivity label
New object labeled with the session sensitivity label.
CREATE INDEX
Session >= database
Session  >= parent catalog
Session  >= parent schema
Session = table
New object labeled with the session sensitivity label.
CREATE SCHEMA
Session >= database
Session >= parent catalog
New object labeled with the session sensitivity label.
CREATE TABLE
Session >= database
Session  >= parent catalog
Session  >= schema 
Session  = table referenced by a foreign key
New object labeled with the session sensitivity label.
CREATE VIEW
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session  >= table
Session  >= view
New object labeled with the session sensitivity label.
DELETE
Session >= database
Session  >= parent catalog
Session  >= parent schema
Session >= table, [view]
Session = row
Delete rows at session sensitivity label.
DROP CATALOG
Session >= database
Session = catalog
Session = any schema, table, or view inside of the catalog
Session = any view that references a table and/or view inside of the catalog
The catalog and all containing objects (if cascade option specified) are dropped.
DROP DATABASE
Session = database
All objects in the database are destroyed.
DROP INDEX
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session = index
Drop the specified index.
DROP SCHEMA
Session >= database
Session  >= parent catalog
Session = schema
Session = any table or view inside of the schema
Session = any view that references a table and/or view inside of the schema
The schema and all containing objects (if cascade option specified) are dropped.
DROP TABLE
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session = table
Session = any view referencing the table
The table, all indices, and all rows are dropped. All referencing views are dropped (if cascade option specified).
DROP VIEW
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session = view
Session = any view referencing the view
The view is dropped. All referencing views are dropped (if cascade option specified).
GRANT
Session >= parent object(s)
Session = object
Privileges valid for all sensitivity labels that may access object.
INSERT
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session >= table, [view]
New object labeled with the session sensitivity label.
REVOKE
Session >= parent object(s)
Session = object
Privileges revoked are applicable for all sensitivity labels that may access object.
SELECT
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session >= table, [view];
Session >= row
Rows dominated by session sensitivity label are returned.
SET CATALOG
Session >= database
Session >= catalog
Specified catalog name used as default catalog name for all future SQL operations.
SET SCHEMA
Session >= database
Session >= parent catalog
Session >= schema
Specified schema name used as default schema name for all future SQL operations.
UPDATE
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session >= table, [view];
Session = row
Rows at the session sensitivity label are updated.
sub-query*
 
Session >= database
Session  >= parent catalog
Session  >= parent schema 
Session >= table, [view];
Session >= row
 
Rows dominated by session sensitivity label are returned for the sub-query.
 
* A sub-query is an implied operation on any delete, update, or select operation that includes a where clause and any insert operation that has a select clause.

MLS Multilevel DBMS Objects

Trusted RUBIX has many DBMS objects that contain child objects. For instance, databases contain catalogs, catalogs contain schemata, schemata contains tables, and tables contain rows. Each of these objects may contain child objects that have a sensitivity label that is different than the parent object. The general MLS rule is that a parent object may contain a child object only if that child object's sensitivity label dominates the parent's sensitivity label. Thus, parents objects are able to hold child objects at the same label or higher.

 

MLS multilevel DBMS objects allow container objects to store information from various sensitivity labels while allowing each user to have a view of the database which corresponds to his clearance label, only seeing objects which are dominated by his clearance. All of this happens automatically within Trusted RUBIX.

 

The following diagram demonstrates a database configuration with multiple MLS multilevel DBMS objects.

 

MLS Multilevel Objects Diagram

Each user will have a view of the database which corresponds to his clearance label. Objects for which the user is not cleared to access (i.e., those which he does not dominate) will be automatically filtered out of the user's view. Polyinstantiation will insure that naming collisions do not reveal the existence of higher level objects.

 

The following diagram shows the logical view a user would have of the database with an Unclassified, Confidential, and Secret clearance. A Top Secret clearance would have all objects visible and present a view of the database that corresponds to the first diagram.

 

Views of MLS Multilevel Objects by Clearance

MLS Table SELECT Example

The following diagram shows the results of two users, with differing MLS session labels, performing a SELECT operation on the same table.

 

The first user, Bob, is connected to Trusted RUBIX with an MLS session label of 'Top Secret: A'. The second user, Nancy, is connected to Trusted RUBIX with an MLS session label of 'Confidential: B'. Both users are selecting all rows from the 'MyTab' table.

 

In both cases, the SELECT result set will contain only rows which the user dominates. Note that both the user's clearance component must be higher than the row's sensitivity component and the user's compartments must include each of the row's compartments. If a user does not dominate a row, then the row is simply filtered from the result set (no error value is returned). Thus, the existence of the row is hidden.

 

The MLS filtering of the table rows occurs within the RDBMS Kernel and below the SQL Engine, making it impossible that an improper row be returned for each SQL operation.

 

MLS Table SELECT Diagram

 

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

 

MLS Concurrency Control

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 locking concurrency control protocols (e.g., two-phase locking or explicitly locking) commonly used within non-secure DBMS products.

 

The illegal information flow is achieved by a high-level user locking a low-level object for read. A low-level user then attempts to lock the object for write. Because the write lock requires a unique lock, it will be delayed or denied because of the existence of the high-level lock. The low-level user can then create a program that exploits the existence (or non-existence) of the locking delay to receive information from the cooperating high-level user. The following diagram demonstrates this process.

 

Insecure Concurrency Control Resulting in an Illegal Information Flow

Trusted RUBIX eliminates the covert channels provided through locking concurrency protocols by using a unique algorithm know as the Secure Multiversion Timestamp Ordering (Secure MVTO) concurrency control protocol. Secure MVTO creates a new version of a row upon every update and uses transaction timestamps to ensure a user operates on the correct row version.

 

In our example, the high-level user never locks the row being read. Additionally, the low-level user never requires a lock on the row, she simply creates a new version of the row alongside the original version.

 

The following diagram demonstrates how Trusted RUBIX and Secure MVTO remove illegal information flows caused by locking concurrency control algorithms.

 

Trusted RUBIX Secure Concurrency Control

 

MLS OS-RDBMS Policy Integration

Trusted RUBIX fully integrates the MLS policy of the underlying secure operating system (OS) with that of the RDBMS. This results in coherent security behavior across both the OS and RDBMS domains.

 

With MLS policy integration, the RDBMS session label and the OS session label will be the same for every user. The string label representation and the set of valid label formats will also be the same for Trusted RUBIX and the secure operating system. Additionally, the dominance relationships (i.e., the security lattice) will be the same.

 

Other RDBMS products that implement MLS policy enforcement may not integrate with the underlying secure operating system or may be designed to operate on top of a non-MLS operating system. In these environments, illegal information flows may occur from the RDBMS, to the OS, and then to a user not cleared to access the information. Additionally, the security administrator may have to maintain and configure two MLS policies, each with differing label structures and security lattices.

 

The first of the following two diagrams demonstrates how a malicious user may illegally send information from Top Secret to Unclassified, by exploiting the lack of OS-RDBMS policy integration. The second diagram demonstrates how Trusted RUBIX prevents this illegal information flow by integrating with the underlying secure operating system.

 

In the first diagram, the malicious user Bob SELECT's Top Secret RDBMS data and redirects it to an Unclassified operating system file. Because there is no OS-RDBMS policy integration, Bob is able to connect to the RDBMS at Top Secret while remaining at Unclassified with respect to the operating system. Nancy then reads the Top Secret RDBMS data from the Unclassified operating system file, completing the illegal information flow.

 

Illegal Information Flow in Systems without OS-RDBMS Policy Integration

The second diagram demonstrates how Trusted RUBIX prevents such illegal information flows by integrating the MLS policies. Because Bob's Trusted RUBIX RDBMS and OS session labels are linked, he can only redirect the RDBMS data into a Top Secret operating system file. Nancy, being at Unclassified is unable to read from the Top Secret operating system file. Thus, the data remains protected by the same MLS policy in both the Trusted RUBIX RDBMS and operating system.

 

Preventing Illegal Information Flow using OS-RDBMS Policy Integration