Of all the enforcement controls that Oracle Label Security permits, the administrator must choose those that meet the needs of the given application.

This means identifying levels of data sensitivity to exposure, alteration, or misuse, as well as identifying which users have the need or the right to access or alter such data. The policy enforcement options enable administrators to fine-tune users' abilities to read or write data or labels.

You can set policy, schema, and table levels of policy enforcement.

Table 11-1 lists the levels on which policy enforcement options can operate.

When you apply a policy to a table or schema, you can specify the enforcement options that are to constrain use of that table or schema. If you do not specify enforcement options at that time, then the default enforcement options you specified when you created that policy are used automatically.

These options customize your policy enforcement to meet your security requirements as to READ access, WRITE access, and label changes. You can also specify whether the label column should be displayed or hidden. You can choose to enforce some or all of the policy options for any protected table by specifying only those you want.

Optionally, you can assign each table a labeling function, which determines the label of any row inserted or updated in that table. You can also specify, optionally, a SQL predicate for a table, to control which rows are accessible to users, based on their labels.

When Oracle Label Security policy enforcement options are applied, they control which rows are accessible to view or to insert, update, or delete.

Oracle Label Security enforces policies using three categories: label management options, access control options, and overriding options.

Table 11-2 lists the categories of policy enforcement options.

• Label management options ensure that data labels written for inserted or updated rows do not violate policies set for such labels

• Access control options ensure that only rows whose labels meet established policies are accessible for SELECT, UPDATE, INSERT, or DELETE operations.

• Overriding options can suspend or apply all other enforcement options.

Remember that even when Oracle Label Security is applicable to a table, some DML operations may not be covered by the policies being applied. The policy enforcement options set by the administrator determine both the SQL processing behavior and what an authorized user can actually see in response to a query on a protected table. Except where noted, this chapter assumes that ALL_CONTROL is active, meaning that all enforcement options are in effect. If users attempt to perform an operation for which they are not authorized, then an error message is raised and the SQL statement fails.

Understanding the relationships among these policy enforcement options, and what SQL statements they control, is essential to their effective use in designing and implementing your Oracle Label Security policies.

Oracle Label Security has a set of policy enforcement options.

Table 11-3 describes the relationships between policy enforcement options.

(*) A row is authorized for READ access if the following three criteria are all met:(user-minimum-level) < = (data-row-level) < = (session-level)(any-data-group) is a child of (any-user-group-or-childgroup) (every-data-compartment) is also in (the user's compartments). Refer to the figure in How Oracle Label Security Algorithm for Read Access Works

(**) A row is authorized for READ access if the following three criteria are all met:(user-minimum-level) < = (data-row-level) < = (session-level)(any-data-group) is a child of (any-user-group-or-childgroup) (every-data-compartment) is also in (the user's compartments). Refer to the figure in How Oracle Label Security Algorithm for Read Access Works.

You can specify the HIDE policy configuration option when you add an Oracle Label Security policy column to a table.

This prevents display of the column containing the policy's labels.

Once the policy has been applied, the hidden (or not hidden) status of the column cannot be changed unless the policy is removed with the DROP_COLUMN parameter set to TRUE. Then, the policy can be reapplied with a new hidden status.

INSERT statements doing all-column inserts do not require the values for hidden label columns.

SELECT statements do not automatically return the values of hidden label columns. Such values must be explicitly retrieved.

A DESCRIBE on a table may or may not display the label column. If the administrator sets the HIDE option, then the label column will not be displayed. If HIDE is not specified for a policy, then the label column is displayed in response to a SELECT.

The three label enforcement options control the data label written when a row is inserted or updated.

• About the Label Management Enforcement Options
  When a policy specifies the options and is applied to a table or schema, these options apply to special situations.
• LABEL_DEFAULT: Using the Session's Default Row Label
  A user can update a row without specifying a label value, because the updated row uses its original label.
• LABEL_UPDATE: Changing Data Labels
  A user updating a row can normally change its label to any label within his authorized label range.
• CHECK_CONTROL: Checking Data Labels
  If an inserted or updated row gets its label from a labeling function, the label could be outside the user’s authorizations.

Access control options limit the rows accessible for SELECT, UPDATE, INSERT, or DELETE operations to only those rows whose labels meet established policies.

• READ_CONTROL: Reading Data
  READ_CONTROL limits the set of records accessible to a session for SELECT, UPDATE and DELETE operations.
• WRITE_CONTROL: Writing Data
  When an Oracle Label Security policy specifying the WRITE_CONTROL option is applied to a table, triggers are generated and the algorithm is enforced.
• INSERT_CONTROL, UPDATE_CONTROL, and DELETE_CONTROL
  The INSERT_CONTROL, UPDATE_CONTROL, and DELETE_CONTROL options control policy enforcement during the corresponding operations on the data columns in a row.

Whereas ALL_CONTROL applies all of the label management and access control enforcement options, NO_CONTROL applies none of them.

In either case, labeling functions and SQL predicates can be applied. Note that the ALL_CONTROL option can be used only on the command line. If you apply a policy with NO_CONTROL specified, then a policy label column is added to the table, but the label values are NULL. Because no access controls are operating on the table, you can proceed to enter labels as desired. You can then set the policy enforcement options as you want. NO_CONTROL can be a useful option if you have a labeling function in force to label the data correctly, but want to let all users access all the data.

You can customize policy enforcement for a schema or table through the Oracle Enterprise Manager.

This functionality is described in Creating an Oracle Label Security Policy or you can use the SA_POLICY_ADMIN package as described in SA_POLICY_ADMIN Policy Administration PL/SQL Package.

This section documents the supported keywords.

Note that when you create a policy, you can specify a string of default options to be used whenever the policy is applied without schema or table options being specified.

If a policy is first applied to a table, and then also applied to the schema containing that table, then the options on the table are not affected by the schema policy. The options of the policy originally applied to the table remain in force.

In general, administrators use the LABEL_DEFAULT policy option, causing data written by a user to be labeled with that user's row label. Alternatively, a labeling function can be used to label the data. If neither of these two choices is used, then a label must be specified in every INSERT statement. (Updates retain the row's original label.)

The following table suggests that certain combinations of policy enforcement options are useful when implementing an Oracle Label Security policy. As the table indicates, you might typically enforce READ_CONTROL and WRITE_CONTROL, choosing from among several possible combinations for setting the data label on writes.

Oracle Label Security has several exceptions from OLS policy enforcement.

These exemptions are as follows:

• Oracle Label Security is not enforced during DIRECT path export.

• By design, Oracle Label Security policies cannot be applied to objects in schema SYS. As a consequence, the SYS user, and users making a DBA-privileged connection to the database (such as CONNECT AS SYSDBA) do not have Oracle Label Security policies applied to their actions. DBAs need to be able to administer the database. It would make no sense, for example, to export part of a table due to an Oracle Label Security policy being applied. The database user SYS is thus always exempt from Oracle Label Security enforcement, regardless of the export mode, application, or utility used to extract data from the database.

• Similarly, database users granted the EXEMPT ACCESS POLICY privilege, either directly or through a database role, are exempted from some Oracle Label Security policy enforcement controls such as READ_CONTROL and CHECK_CONTROL, regardless of the export mode, application or utility used to access the database or update its data. The following policy enforcement options remain in effect even when EXEMPT ACCESS POLICY is granted:

  • INSERT_CONTROL, UPDATE_CONTROL, DELETE_CONTROL, WRITE_CONTROL, LABEL_UPDATE, and LABEL_DEFAULT.

  • If the Oracle Label Security policy specifies the ALL_CONTROL option, then all enforcement controls are applied except READ_CONTROL and CHECK_CONTROL.

  EXEMPT ACCESS POLICY is a very powerful privilege and should be carefully managed.

  Note that this privilege does not affect the enforcement of standard Oracle Database object privileges such as SELECT, INSERT, UPDATE, and DELETE. These privileges are enforced even if a user has been granted the EXEMPT ACCESS POLICY privilege.

Oracle Label Security provides data dictionary views that describe the policy enforcement options currently applied to tables and schemas.

• DBA_SA_TABLE_POLICIES

• DBA_SA_SCHEMA_POLICIES

There are three ways to label data that is being inserted or updated.

• You can explicitly specify a label in every INSERT or UPDATE to the table.

• You can set the LABEL_DEFAULT option, which causes the session's row label to be used if an explicit row label is not included in the INSERT or UPDATE statement.

• You can create a labeling function, automatically calls on every INSERT or UPDATE statement and independently of any user's authorization.

The recommended approach is to write a labeling function to implement your rules for labeling data. If you specify a labeling function, then Oracle Label Security embeds a call to that function in INSERT and UPDATE triggers to compute a label.

For example, you could create a labeling function named my_label to use the contents of COL1 and COL2 of the new row to compute and return the appropriate label for the row. Then, you could insert, into your INSERT or UPDATE statements, the following reference:

my_label(:new.col1,:new.col2)

If you do not specify a labeling function, then specify the LABEL_DEFAULT option. Otherwise, you must explicitly specify a label on every INSERT or UPDATE statement.

Labeling functions enable you to consider, in your rules for assigning labels, information drawn from the application context.

For example, you can use as a labeling consideration the IP address to which the user is attached. There are many opportunities to use SYS_CONTEXT in this way.

Labeling functions override the LABEL_DEFAULT and LABEL_UPDATE options.

A labeling function is called in the context of a before-row trigger. This enables you to pass in the old and new values of the data record, as well as the old and new labels.

You can construct a labeling function to permit an explicit label to be passed in by the user.

All labeling functions must have return types of the LBACSYS.LBAC_LABEL data type. The TO_LBAC_DATA_LABEL function can be used to convert a label in character string format to a data type of LBACSYS.LBAC_LABEL. Note that LBACSYS must have the EXECUTE privilege on your labeling function. The owner of the labeling function must have the EXECUTE privilege on the TO_LBAC_DATA_LABEL function, with the GRANT option.

You can use the CREATE OR REPLACE FUNCTION SQL statement to create a labeling function.

CREATE OR REPLACE FUNCTION sa_demo.gen_emp_label
           (Job varchar2,
            Deptno number,
            Total_sal number)
       Return LBACSYS.LBAC_LABEL
     as
       i_label varchar2(80);
     Begin
       /************* Determine Class Level *************/
       if total_sal > 2000 then
       i_label := 'L3:';
       elsif total_sal > 1000 then
       i_label := 'L2:';
       else
       i_label := 'L1:';
       end if;
     
       /************* Determine Compartment *************/
       IF Job in ('MANAGER','PRESIDENT') then
       i_label := i_label||'M:';
       else
       i_label := i_label||'E:';
       end if;
       /************* Determine Groups *************/
       i_label := i_label||'D'||to_char(deptno);
       return TO_LBAC_DATA_LABEL('human_resources',i_label);
     End;
     /

You can use the SA_POLICY_ADMIN package to specify a labeling function.

SA_POLICY_ADMIN.REMOVE_TABLE_POLICY('human_resources','sa_demo','emp');
  

SA_POLICY_ADMIN.APPLY_TABLE_POLICY(
  POLICY_NAME     => 'human_resources',
  SCHEMA_NAME     => 'sa_demo',
  TABLE_NAME      => 'emp',
  TABLE_OPTIONS   => 'READ_CONTROL,WRITE_CONTROL,CHECK_CONTROL',
  LABEL_FUNCTION  => 'sa_demo.gen_emp_label(:new.job,:new.deptno,:new.sal)',
  PREDICATE       => NULL);

When you attempt to insert or update data based on your authorizations, the outcome depends upon what policy enforcement controls are active.

• If INSERT_CONTROL is active, then rows you insert can only have labels within your write authorizations. If you attempt to update data that you can read, but for which you do not have write authorization, an error is raised. For example, if you can read compartments A and B, but you can only write to compartment A, then if you attempt to insert data with compartment B, then the statement will fail.

• If INSERT_CONTROL is not active, then you can use any valid label on rows you insert.

• If the CHECK_CONTROL option is active, then rows you insert can only have labels you are authorized to read, even if the labels are generated by a labeling function.

A labeling function takes precedence over labels entered by the user.

If the administrator has set up an automatic labeling function, then no data label a user enters will have effect (unless the labeling function itself makes use of the user's proposed label). New row labels are always determined by an active labeling function, if present.

Note that a labeling function can set the label of a row being inserted to a value outside the range that the user writing that row can see. If such a function is in use, then the user can potentially insert a row but not be authorized to see that row. You can prevent this situation by specifying the CHECK_CONTROL option in the policy. If this option is active, then the new data label is checked against the user's read authorization, and if the user cannot read it, then the insert operation is not performed.

If declarative referential integrity protects a parent table, then the parent row must be visible before a child row can be inserted.

The user must be able to see the parent row for the insert operation to succeed, that is, the user must have read access to the parent row.

If READ_CONTROL is active on the parent table, then the user's read authorization must be sufficient to authorize a SELECT operation on the parent row. For example, a user who cannot read department 20 cannot insert child rows for department 20. Note that all records will be visible if the user has FULL or READ privileges on the table or schema.

To change a row label from SENSITIVE to CONFIDENTIAL, you can change the label by using the CHAR_TO_LABEL function.

UPDATE emp 
SET hr_label = char_to_label ('HR', 'CONFIDENTIAL')
WHERE ename = 'ESTANTON';

When you attempt to update data based on your authorizations, the outcome depends on which enforcement controls are active.

• If UPDATE_CONTROL is active, then you can only update rows whose labels fall within your write authorizations. If you attempt to update data that you can read, but for which you do not have write authorization, then an error is raised. Assume, for example, that you can read compartments A and B, but you can only write to compartment A. In this case, if you attempt to update data with compartment B, then the statement will fail.

• If UPDATE_CONTROL is not active, then you can update all rows to which you have read access.

• If LABEL_UPDATE is active, then you must have the appropriate privilege (WRITEUP, WRITEDOWN, or WRITEACROSS) to change a label by raising or lowering its sensitivity level, or altering its groups or compartments.

• If LABEL_UPDATE is not active but UPDATE_CONTROL is active, then you can update a label to any new label value within your write authorization.

• If CHECK_CONTROL is active, then you can only write labels you are authorized to read.

The following figure illustrates the label evaluation process for LABEL_UPDATE.

Figure 11-1 Label Evaluation Process for LABEL_UPDATE

Description of "Figure 11-1 Label Evaluation Process for LABEL_UPDATE"

A labeling function takes precedence over labels entered by the user.

If the administrator has set up an automatic labeling function, then no label a user enters will have effect (unless the labeling function itself makes use of the user's proposed label). New row labels are always determined by an active labeling function, if present.

Note that the security administrator can establish a labeling function that sets the label of a row being updated to a value outside the range that you can see. If this is the case, then you can update a row, but not be authorized to see the row. If the CHECK_CONTROL option is on, then you will not be able to perform such an update. The CHECK_CONTROL option verifies your read authorization on the new label.

If a child row is in a table with a referential integrity constraint, then the parent row must be visible for the update to succeed.

That is, this user must be able to see the parent row.

If the parent table has READ_CONTROL on, then the user's read authorization must be sufficient to authorize a SELECT on the parent row.

For example, a user who cannot read department 20 in a parent table cannot update an employee's department to department 20 in a child table. (If the user has FULL or READ privilege, then all records will be visible.)

A SQL predicate is a condition, optionally preceded by AND or OR.

The SQL predicate can be appended for READ_CONTROL access mediation. The following predicate, for example, adds an application-specific test based on COL1 to determine if the session has access to the row.

AND my_function(col1)=1

The combined result of the policy and the user-specified predicate limits the rows that a user can read. So, this combination affects the labels and data that CHECK_CONTROL will permit a user to change. An OR clause, for example, increases the number of rows a user can read.

A SQL predicate can be useful if you want to avoid performing label-based filtering. In certain situations, a SQL predicate can easily implement row-level security on tables. Used instead of READ_CONTROL, a SQL predicate will filter the data for SELECT, UPDATE, and DELETE operations.

Similarly, in a typical, Web-enabled human resources application, a user might have to be a manager to access rows in the employee table. In such cases, the user's user label would have to dominate the label on the employee's row. A SQL predicate like the following could be added, so that an employee could bypass label-based filtering if he wanted to view his own record in the employee table. (An OR is used so that either the label policy will apply, or this statement will apply.)

OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = employee_name

This predicate enables you to have additional access controls so that each employee can access his or her own record.

You can use such a predicate in conjunction with READ_CONTROLs or as a standalone predicate even if READ_CONTROL is not implemented.

Predicates can be appended to other predicates.

A predicate applied to a table with an Oracle Label Security policy is appended to other predicates that are applied by other Oracle Label Security policies, or by Oracle Database fine-grained access control or Oracle Virtual Private Database policies. The predicates are ANDed together.

Consider the following predicates applied to the EMP table in the SCOTT schema:

• A predicate generated by an Oracle VPD policy, such as deptno=10

• A label-based predicate generated by an Oracle Label Security policy, such as label=100, with a user-specified predicate such as

  OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = ename

Correct: These predicates would be ANDed together as follows:

WHERE deptno=10 AND (label=100 OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = ename)

Incorrect: The predicates would not be combined in the following way:

WHERE deptno=10 AND label=100 OR SYS_CONTEXT ('USERENV', 'SESSION_USER') = ename