Security Policy Enforcement - Archive

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

Multilevel Security (MLS): DBMS 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).
Type Enforcement (TE, SELinux only): User sessions are assigned domains and DBMS 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 DBMS operation being performed.
Attribute Based Access Control (ABAC): XML policies (based upon the XACML standard) are assigned to named DBMS objects and control the DBMS operations that may be performed on that object. Modular and dynamic policy logic uses numerous DBMS 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).
Role Based Access Control (RBAC): Named roles are given a set of authorizations (the ability to perform one or more DBMS 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 DBMS client based actions (e.g., connect to a database) and DBMS administrative actions (e.g., backup the database).
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.

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 rules for the policy; and
what is the configuration for the policy.

Trusted RUBIX Access Control Policies


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 by any user. OS Security Admin inspects and assignes policies to the OS. Policies may cover DBMS and OS objects allowing for coherent policies.
Attribute Based Access Control	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 by any user. DBMS Security Admin inspects and assigns policies to DBMS objects. Policies may be inherited from parent object.
Role Based Access Control	Yes	Mandatory	A set of authorizations are mapped to a named role. Each authorization allows the execution of one or more actions. 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.	Normal DBMS users grant/revoke access to objects they control. Part of SQL language.

¹The OS is consulted for policy decisions allowing for coherent policy behavior across DBMS and OS operations and objects. The DBMS user’s session label (context) is extracted from the OS process or socket. For RBAC, each role is recognized by both the OS and DBMS and may give both OS and DBMS 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 DBMS 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 DBMS is shown in the following diagram and indicates the following:

the location of policy access checks relative to the SQL Engine and DBMS 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 DBMS module directly below it. The DAC policy operates over SQL Engine operations and objects while all other policies operate over DBMS 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 DBMS objects are shown (the RBAC policy is not shown).

Infosystems Technology, Inc.

Security Policy Enforcement - Archive