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.
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.
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.
Sample Sensitivity/Clearance ordering are:
Sample Compartment intersections are:
Formally, for label1 to dominate label2 both of the following must be true:
The dominance relationship will produce a partial ordering over all possible MLS labels, resulting in what is known as the MLS Security Lattice.
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.
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
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:
The following table enumerates the MLS access control rules for each SQL operation.
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.
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
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.
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:
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.
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.
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.
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 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