Rules Associated with a Security Policy

The WITH IDSLBACRULES keywords specify the read access rules and write access rules that the new security policy enforces. If you do not specify them, these keywords are in effect by default, because the IDSLBACRULES access rules are the only access rules that the a security policy can support.

The following IDSLBACRULES access rules for read access, called IDSLBACREAD, apply when data values are read from labeled rows or columns in SELECT, UPDATE, or DELETE operations:
  • IDSLBACREADARRAY: Each array component of the user security label must be greater than or equal to the array component of the data row security label. That is, only data at or below the level of the user can be read.
  • IDSLBACREADTREE: Each tree component of the user security label must include at least one of the elements in the tree component of the data row security label (or the ancestor of one such element).
  • IDSLBACREADSET: Each set component of the user security label must include the set component of the data row security label.
The following IDSLBACRULES access rules for write access, called IDSLBACWRITE, apply when data values are written to labeled rows or columns in INSERT, UPDATE, or DELETE operations:
  • IDSLBACWRITEARRAY: Each array component of the user security label must be equal to the array component of the data row security label. That is, only data at the same level as the user can be written.
  • IDSLBACWRITETREE: Each tree component of the user security label must include at least one of the elements in the tree component of the data row security label (or the ancestor of one such element).
  • IDSLBACWRITESET: Each set component of the user security label must include the set component of the data row security label.

If DBSECADM omits the WITH IDSLBACRULES keywords, then those rules are in effect by default. If any specification except IDSLBACRULES follows the WITH keyword, however, the CREATE SECURITY POLICY statement fails with an error, and no security policy is created.

Besides the explicit or default WITH IDSLBACRULES keywords, the CREATE SECURITY POLICY statement must also specify the write access rule to enforce when a user is not authorized to write the explicitly specified security label provided in the DELETE, INSERT, or UPDATE statement for a table protected with this security policy. The security label of the user and the exemption credentials that the user holds determine whether the user has write access to an explicitly provided security label.
  • If the CREATE SECURITY POLICY statement specifies OVERRIDE NOT AUTHORIZED WRITE SECURITY LABEL, then HCL OneDB™ uses the value of the user security label, rather than the security label that is explicitly specified in the DELETE, INSERT, or UPDATE statement, to determine whether the user has write-access to data values that are protected by a security label in the DELETE, INSERT, or UPDATE operation.
  • The default is RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL. If you specify these keywords explicitly, or if they are in effect by default, then DELETE, INSERT, or UPDATE statements fail with an error if the user is not authorized to write data in a row or column that has the explicitly specified security label.
The following example creates a security policy called MegaCorp that uses three security label components, with no OVERRIDE provision for the user security label to provide write access in DELETE, INSERT, or UPDATE operations on data whose explicitly specified security label does not authorize write access for that user: 
CREATE SECURITY POLICY MegaCorp
   COMPONENTS levels, compartments, groups
      WITH IDSLBACRULES;
For this example to be valid, the levels, compartments, and groups security label components (or components that have been renamed to these identifiers) must have been previously defined by the CREATE SECURITY LABEL COMPONENT statement.