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. |
Trusted RUBIX enforces five distinct security policies. In general, each policy must permit an operation for it to be successful.
|
The Trusted RUBIX Access Control Policies are listed in the table below and indicate the following:
|
Policy |
OS Integration1 |
Type2 |
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 update objects with equal levels. |
Policy rules are fixed. |
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. |
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. |
1 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. | ||||
2 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. |
The security policy architecture of the Trusted RUBIX RDBMS is shown in the following diagram and indicates the following:
Trusted RUBIX Security Archectecture |