Security Policy Enforcement

Trusted RUBIX enforces five distinct security policies: Multilevel Security (MLS), Type Enforcement (TE, SELinux only), Attribute Based Access Control/SPM (ABAC), TR Role Based Access Control (RBAC), and Discretionary Access Control (DAC). All but the DAC policy are mandatory policies in that normal database users have no control over their enforcement or configuration. The three MAC mechanisms of MLS, TE, and RBAC policies have full integration with the equivalent policies in the underlying operating system. The integrated MAC provides unified and coherent security behavior across all database and operating system objects. This simplifies security administration and prevents security violations when information moves between the database (e.g., a table) and the operating system (e.g., a file).

Mandatory Access Control (MAC) is the ability of a system to control access to specific data based upon a set of mandatory rules (i.e., a policy) defined by administrative personnel (e.g., the Security Administrator). MAC is enforced for every object and every operation in the system. MAC provides the highest level of security because neither the normal user nor the owner of an object has any influence over the policy that control access to the data. MAC effectively provides a protective wall around all data in the system and only the Security Administrator determines which data passes through the wall's single gate, based upon the user and the specific data being accessed.

To ensure the proper enforcement of these security policies, Trusted RUBIX uses an internal design that focuses on the modularity and layering principles which are critical in high assurance systems. The RDBMS mandatory policies are implemented as a minimized reference monitor within the database kernel. No query modification or SQL engine "hooks" are used.

The security policies are enforced over all RDBMS objects and operations, including the data dictionary. Polyinstantiation of RDBMS objects is used to prevent classified information from being inferred by non-cleared users who, during object creation, attempt to exploit unique object name conflicts between security domains. Furthermore, Trusted RUBIX uses a unique secure concurrency algorithm that removes covert channels between transactions of different security domains as they access common database objects. These features ensure that information is not leaked through "back-door" channels.

To find out more about the security policies enforced by the Trusted RUBIX RDBMS please follow the links below.

Overview of Security Policies

Trusted RUBIX enforces five distinct security policies. In general, each policy must permit an operation for it to be successful.

Multilevel Security (MLS): RDBMS objects and user sessions are assigned classifications levels. Fixed Bell-La Padula rules define allowable operations (users allowed to read objects with dominated classifications, users allowed to write objects with equal classifications). Trusted RUBIX labels its objects with the same MLS labels and security lattice as used by the underlying trusted operating system (TOS).

Type Enforcement (TE, SELinux only): User sessions are assigned domains and RDBMS objects are assigned types. A scripting language is used to define which type is assigned to an object and which domain is assigned to a user session. The scripting language is also used to define if a user session may perform an operation on an object given the user session's domain, the object's type, and the RDBMS operation being performed. TE policy provides custom rules for requirements in cross domain environments. For an example of TE policy in such environments see: http://rubix.com/cms/te_xdomain.

Attribute Based Access Control/SPM (ABAC): XML policies (based upon the XACML standard) are assigned to named RDBMS objects and control the RDBMS operations that may be performed on that object. Modular and dynamic policy logic uses numerous RDBMS attributes and consists of rules, policies, and policy sets. Policy driven actions may also be performed (e.g., produce a custom audit record, calculate and set a column value). Policies may be updated and applied in "real-time" and be configured to override the MAC policy. ABAC security policies are enforced by the TR Security Policy Manager (SPM). For an example of a policy which releases information in a cross domain environment see: http://rubix.com/cms/abac_xdomain.

TR Role Based Access Control (RBAC): Named roles are given a set of authorizations (the ability to perform one or more RDBMS actions). Each role is assigned to any number of users. A user assumes a single role at a time and may transition between roles. The set of actions a user may perform is bounded by its current role. RBAC may cover RDBMS client based actions (e.g., connect to a database) and RDBMS administrative actions (e.g., backup the database). The authorizations allow rows to be constructed that divide the administrative power between users (separation of duties).

Discretionary Access Control (DAC): Traditional SQL standard access control mechanism. An Access Control List consisting of the user/group ID, the object name, and the SQL operation is used to control access to objects.

Security Policy Comparison Matrix

The Trusted RUBIX Access Control Policies are listed in the table below and indicate the following:

is the policy integrated with the OS policy;
is the policy discretionary or mandatory;
what are the characteristics of the policy rules; and
how is the policy configured.

**Trusted RUBIX Security Policy Comparison Matrix**
Policy	OS Integration¹	Type²	Policy Rules	Policy Configuration
Multilevel Security	Yes	Mandatory	Fixed Bell-Lapadula rules. Based upon primitive read, update, and create operations. Objects assigned level of creating subject. Subjects may read objects with dominated levels. Subjects may update objects with equal levels.	Policy rules are fixed.
Type Enforcement SELinux only	Yes	Mandatory	Rules define which role a user may assume. Roles determine set of domains a subject may have. Rules define the type of an object based upon the creating subject’s domain and the parent object’s type. Rules define an Access Control List over subject domain, object type, and SQL operation.	Script based policies created in OS files. OS Security Admin inspects and assignes policies to the OS. Policies may cover RDBMS and OS objects allowing for coherent policies.
Attribute Based Access Control/SPM	No	Mandatory	Flexible and dynamic modular policies based upon numerous attributes, including any row value. MLS and TE policy decisions useable as attributes. XACML based rules control access to SQL operation. Policy decision may override MLS and TE. Policy driven actions (audit, set column value) may be performed.	XML policies created in OS files. RDBMS Security Admin inspects and assigns policies to RDBMS objects. Policies may be inherited from parent object.
TR Role Based Access Control	Yes	Mandatory	Each authorization allows the execution of one or more actions. A set of authorizations are mapped to a named role. Each role may be associated with any number of users. A user may transition between roles and is in exactly one role at any given time. The actions a user may perform are bounded by its current role.	OS dependent. SELinux: Scripted Type Enforcement policy rules include definitions for roles and specify the ability to transition between them. Roles are assigned to users using a GUI. Solaris: Roles are configured by associating a set of authorizations using a GUI. Roles are assigned to users using a GUI.
Discretionary Access Control	No	Discretionary	Access Control List over User ID/Group ID, object name, and SQL operation. Non-administrative users distribute permissions to access objects they create.	Normal RDBMS users grant/revoke access to objects they control. Ability to grant/revoke may itself be granted and revoked. Part of SQL language.
¹ The OS is consulted for policy decisions allowing for coherent policy behavior across RDBMS and OS operations and objects. The RDBMS user’s session label (context) is extracted from the OS process or socket. For RBAC, each role is recognized by both the OS and RDBMS and may give both OS and RDBMS abilities.
² A discretionary policy is one in which the ability to allow or deny an operation is given to the object’s owner or other non-administrative RDBMS users. A mandatory policy is one in which only an administrator may configure which users may perform an operation.

Trusted RUBIX Security Architecture

The security policy architecture of the Trusted RUBIX RDBMS is shown in the following diagram and indicates the following:

The location of policy access checks relative to the SQL Engine and RDBMS Kernel is represented by the position of the box labeled with the security policy name. Policy access checks are executed over operations and objects in the RDBMS module directly below it. The DAC policy operates over SQL Engine operations and objects while all other policies operate over RDBMS Kernel operations and objects. A policy being above another policy implies that it is evaluated after the other policy.

The values each policy uses to calculate its security decision are enumerated in the rectangular box to the right of the box labeled with the security policy name.

The basic characteristics of each security policy's rules are listed under the security policy name.

Note that only security policies that operate directly on RDBMS objects are shown (the TR RBAC policy is not shown).

Trusted RUBIX Security Archectecture