Trusted RUBIX enforces four distinct security policies: operating system mandatory access policy (OS-MAC), attribute based access control (ABAC), discretionary access control (DAC), and role based access control (RBAC). All but the DAC policy are mandatory policies in that normal database users have no control over their enforcement or configuration. For a database operation to be permitted all security policies must permit the operation.

The OS-MAC policy is tightly integrated with the host trusted operating system. All host operating systems support a multilevel security policy. In addition SELinux supports a type enforcement (TE) policy. The OS-MAC policies are fully integrated into Trusted RUBIX to control all database operations and objects. The security attributes (i.e., labels) and the access control rules (i.e., the MLS security lattice or TE enforcement logic) of the operating system are the same as those used in the DBMS giving a coherent security policy across the entire system.

The ABAC policy, based upon the OASIS XACML 2.0 standard, allows highly custom security policies to be created based upon various attributes of the database. Example attributes include values of database fields, the current time, and the OS-MAC label. ABAC policies may be organized into policy sets allowing for modular policy creation. Database actions (e.g., change the value of a row or create an audit record) may be associated with the outcome of ABAC policies.

The DAC policy is the typical SQL security policy. The creator of a database object is allowed to grant privileges to other users allowing them to perform SQL operations. The policy is known as discretionary because the security policy is configured at the “discretion” of the object owner and all users they allow to configure the policy.

The RBAC policy allows groups of administrative authorizations to be assigned to named roles. Users may then be associated with the named roles allowing the user to perform all authorized operations. The authorizations are highly granular and are used to create custom administrative users allowing the trust given administrators to be sufficiently divided.

Labels and Security Lattice

Trusted RUBIX uses the binary representation of a sensitivity label as provided by the underlying secure operating system. No configuration is needed to enable Trusted RUBIX to use any label that is valid for the operating system. Also, Trusted RUBIX uses operating system services to calculate the dominance relationship between labels ensuring coherent MLS behaviors across the RDBMS and OS.

Database Object Labeling

Trusted RUBIX stores an object sensitivity label with every database object (database, catalog, schema, view, table, index, constraint, and row). The object sensitivity label is set to the creating subject’s session sensitivity label at the time the object is created. The object sensitivity label is maintained within Trusted RUBIX’s security kernel as a fully “autonomous” object. That is, the object’s label is not simply an extra column in a table (although it is possible to select it as a column). There is no provision to alter the labeling of objects.

Database Storage Isolation

All database data is stored in operating system files called volumes. Each volume is labeled, with respect to the operating system, at system high. This prevents any user application from reading or writing the database volumes. The Trusted RUBIX server process executes at system high when accessing the database volumes. The Trusted RUBIX server process achieves the system high label by being created by the Trusted RUBIX Dispatcher, which executes at system high. The server process has no privilege to alter its process label.

Database Session Label

The database session label is set to the label of the process executing the database client program. This label may be explicit, as is the case when the client is executing on an MLS operating system, or implicit as is the case when the client is executing on a Non-MLS operating system (e.g., MS Windows). In the latter case, the client’s session label is configured using the trusted networking facilities of the operating system hosting Trusted RUBIX. In each case, the server process reads the client’s session label from the trusted socket used to communicate between the client and server. The server then sets the database session label and uses it to arbitrate all database operations submitted by the client.

Database Server Instantiation

There is a single Trusted RUBIX server process for each concurrent database session. This dedicates a single process to each active security domain resulting in a high degree of separation between executing subjects. The Trusted RUBIX Dispatcher is responsible for maintaining server processes. The Dispatcher runs persistently with a system high session label. As a client requests a database session, a socket message is sent to the Dispatcher requesting a server. The Dispatcher either responds with an idle server or instantiates a new server. When a new server is instantiated, the server process inherits the system high session label and special user/group ID of the Dispatcher allowing it to access the isolated database storage objects. After the client receives the response from the Dispatcher indicating the server to connect with, the client and server negotiate the start of the database session. The server process reads the client’s session label from the trusted socket and sets the database session label. If the new database session label is different from the previous database session label, all database objects are closed and re-opened. It is important to note that in no way does the server trust the Dispatcher in determining the client’s database session label.

MLS SQL and Relational Model

Trusted RUBIX uses a version of the Structured Query Language (SQL) that has been modified to conform to the MLS security policy. The behavior of each operation reflects restrictions imposed by the policy. In general, create operations result in labels being applied to the new objects, update operations are restricted to objects of the same label as the subject, and reads return only objects which are dominated by the subject. Special provisions to the metadata are made to allow selecting the label of objects. Also, provisions are made to select one or all of any polyinstantiated objects. Also, the relational model has been modified to conform to MLS. A database object may reside in another database object (as a row resides in a table) only if the containing object is dominated by the contained object. For instance, all objects (e.g., tables) inside a database object dominate the database object label and all rows inside a table dominate the table’s label. Polyinstantiation is fully supported to remove implicit information flows due to name collisions.