8 Implementing Policy Enforcement Options and Labeling Functions

8.1.1 Overview of Policy Enforcement Options

Of all the enforcement controls that Oracle Label Security permits, the administrator must choose those that meet the needs Such As? need principles and examples, as in when use what, why?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.

These options can operate at three levels:

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.

Table 8-2, "Policy Enforcement Options" lists the options in three categories:

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

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

• Overriding options, which 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.

Table 8-2, "Policy Enforcement Options" indicates these relationships.

(*) 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 Figure 3-7, "Label Evaluation Process for Read Access"

(**) 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 Figure 3-7, "Label Evaluation Process for Read Access".

8.1.2 The HIDE Policy Column Option

You can specify the HIDE policy configuration option when you initially apply an Oracle Label Security policy to a table, that is, when adding the policy column to the 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.

8.1.3 The Label Management Enforcement Options

The three label enforcement options control the data label written when a row is inserted or updated. When a policy specifies these options and is applied to a table or schema, these options apply to the situations described in this section.

A user inserting a row can specify any data label within the range of the user's label authorizations. If the user does not specify a label for the row being written, LABEL_DEFAULT can do so. Updates can be restricted by LABEL_UPDATE. Inserts or updates that use a labeling function can need CHECK-CONTROL to prevent assigning a data label outside the user's authorizations. Such a label would prevent the user from accessing the row just written, and could enable the user to make data available inappropriately.

Any labeling function in force on a table overrides these options. Such a function can be named in the call that applies the policy to the table. If the administrator named such a function when applying a policy, but then disables or removes that policy, then that function is no longer applied.

8.1.4 The Access Control Enforcement Options

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

• WRITE_CONTROL: Writing Data

• INSERT_CONTROL, UPDATE_CONTROL, and DELETE_CONTROL

8.1.5 The Overriding Enforcement Options

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. Oracle Policy Manager does not provide this as an alternative to selecting individual options.

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 wish.

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.

8.1.6 Guidelines for Using the Policy Enforcement Options

You can customize policy enforcement for a schema or table through the Oracle Policy Manager as described in Chapters 3 & 6, or by using the SA_POLICY_ADMIN package as described in Chapter 8.

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. JEL: better expl'n/example? :JEL

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.

8.1.7 Exemptions from Oracle Label Security Policy Enforcement

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

   
   

   See Also: "Using the Export Utility with Oracle Label Security"

   
   

2. 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.

   
   

   See Also: For other DBA-related considerations, see Chapter 13, " Performing DBA Functions Under Oracle Label Security".

   
   

3. 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. Refer to Table 8-2, "Policy Enforcement Options". 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.

8.1.8 Viewing Policy Options on Tables and Schemas

Use the following views to show the policy enforcement options currently applied to tables and schemas:

• DBA_SA_TABLE_POLICIES

• DBA_SA_SCHEMA_POLICIES

8.2.1 Labeling Data Rows under Oracle Label Security

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

• Explicitly specify a label in every INSERT or UPDATE to the table.

• 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.

• Create a labeling function, automatically calls on every INSERT or UPDATE statement and independently of any user's authorization. JEL: named where? in the policy APPLY? or in every INSERT/UPDATE? please advise. :JEL

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: JEL: are the above changes accurate? please advise :JEL

my_label(:new.col1,:new.col2) JEL: please explain how this works JEL

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.

8.2.2 Understanding Labeling Functions in Oracle Label Security Policies

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. JEL: (a) How can we make LBACSYS less mysterious? !!?? (b) How can we be a bit more specific re the required EXECUTEs? JEL

8.2.3 Creating a Labeling Function for a Policy

The following example shows how to create a labeling function.

SQL> 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;
     /

8.2.4 Specifying a Labeling Function in a Policy

The following example uses the sa_demo.gen_emp_label label from the example in the previous section to show how 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);

8.3.1 Evaluating Enforcement Control Options and INSERT

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. JEL: if have write access on one group, ok, but how get write access to only one compartment of several present? If no groups, must have write access on ALL compartments; fig 3-8 on p3-18 ?? JEL

• 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.

8.3.2 Inserting Labels When a Labeling Function Is Specified

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.

8.3.3 Inserting Child Rows into Tables with Declarative Referential Integrity Enabled

If a parent table is protected by declarative referential integrity, then inserting a child row is constrained by the requirement that the parent row be visible. 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.

8.4.1 Updating Labels Using CHAR_TO_LABEL

If you need to change a row's label from SENSITIVE to CONFIDENTIAL, then you can change the label by using the CHAR_TO_LABEL FUNCTION as follows:

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

8.4.2 Evaluating Enforcement Control Options and UPDATE

When you attempt to update data based on your authorizations, the outcome depends on what 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 8-1 Label Evaluation Process for LABEL_UPDATE

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

8.4.3 Updating Labels When a Labeling Function Is Specified

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.

8.4.4 Updating Child Rows in Tables with Declarative Referential Integrity Enabled

If a child row is in a table that has a referential integrity constraint, then the update can succeed only if the parent row is visible that is the 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.)

8.6.1 Modifying an Oracle Label Security Policy with a SQL Predicate

A SQL predicate is a condition, optionally preceded by AND or OR. It 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.

8.6.2 Affecting Oracle Label Security Policies with Multiple SQL Predicates

A predicate applied to a table by means of an Oracle Label Security policy is appended to any other predicates that may be applied by other Oracle Label Security policies, or by Oracle fine grain access control/VPD 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