You are hereAttribute Based Access Control/SPM / Example: Cross Domain Releasability

Example: Cross Domain Releasability


This example demonstrates policy which releases information across security domains using very specific requirements. In this example we have two distinct security domains, domain1 and domain2. We will use the OS-MAC MLS policy to provide basic separation between domain1 and domain2 and use the Trusted RUBIX ABAC to write highly specific rules to allow controlled information flows between the two domains.

 

To see a detailed description of this example, please see the Trusted RUBIX Security Policy Manager Tutorial.

 

The security requirements are:

  • Two domains: domain1 and domain2
  • domain1 statically connected from the 'Confidential Able' label
  • domain2 statically connected from the 'Confidential Baker' label
  • Single table (XDomainTable) in domain1 containing information regarding US government employees with three columns: Name, PayGrade, and Org
  • Read-write access by domain1 to all rows of table
  • Read-only access by domain2 to a subset of rows in the table where PayGrade is less than ten
  • Users from domain2 must not see actual values of Org (e.g., NSA, CIA) but shall see a “cover” of 'US Government'
  • The Name field of rows that domain2 sees must be audited
  • No access by domain2 to remainder of rows in the table where PayGrade is greater than or equal to 10

The following diagram shows the architecture of the solution along with the results of both domains issuing a SELECT query.  Note that domain1 sees all of the rows unaltered while domain2 sees only a subset of the rows with the Org field statically set to a literal value (US Government). Also note that row data is audited only when the policy permits access by domain2 to a row.

 

The RXSML security policy code is organized into four policies (xdomain-select, mac_check, deny, and xdomain-open) and two policy sets (table-obj and open-obj). The following diagram shows the policies and policy sets and how they interrelate. Note that a policy may be used within multiple policy sets allowing modular policies and reusable code. Though not shown, a policy set may also be used within multiple other policy sets.

 

Policy and Policy Set descriptions and code are:

(Click the links on the policy names to see the corresponding RXSML policy code.)

 

The mac-check Policy: Performs an OS-MAC security policy check on the current operation, evaluating to Permit if the operating system's MAC policy would allow the operation. The RXSML language provides a single function called MAC-check to query the OS-MAC policy. The function will return TRUE if the operating system's MAC policy would allow the operation and FALSE otherwise. 

 

The deny Policy: Always denies the operation. Used as the "catch-all" policy within policy sets when no other policy within the policy set permits an operation.

 

The xdomain-open Policy: Allows users from domain2 to open RDBMS objects that were created within domain1. By design, this policy supersede the underlying OS-MAC policy. Note that this policy is targeted to OPEN operations from subjects at the 'C Baker' session label (i.e., domain2 subjects). It will have no effect on other operations.

 

The xdomain-select Policy: This policy contains the bulk of the cross-domain logic. It targets only SELECT operations from subjects at the 'C Baker' session label (i.e., domain2 subjects). If the value of the PayGrade field of the row being selected is less-than 10, the operation is permitted. Additionally, if the operation is permitted, the Org field of the row being read is set to 'US Government' and the Name field of the row is audited, along with common audit information.

 

The open-obj Policy Set: This policy set contains all logic needed for domain1 and domain2 subjects to open domain1 parent objects (database, catalog, and schema). The included policies are evaluated in order and the first Permit results in the policy set evaluating to Permit. If no included policy evaluates to Permit, then the deny policy will cause the policy set to evaluate to Deny. The mac-check policy will permit domain1 subjects OPEN operations while the xdomain-open policy will permit OPEN operations for domain2 subjects.

 

The table-obj Policy Set: This policy set contains all logic needed for domain1 and domain2 subjects to perform operations on the XDomainTable table. The included policies are evaluated in order and the first Permit results in the policy set evaluating to Permit. If no included policy evaluates to Permit, then the deny policy will cause the policy set to evaluate to Deny. The mac-check policy will permit domain1 subjects table operations, the xdomain-open policy will permit OPEN operations for domain2 subjects, and the xdomain-select policy will permit restricted SELECT operations from domain2 subjects.