8
Implementing Policy Enforcement Options and Labeling Functions

Exemptions from O racle 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 SY SDBA) 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 extr act data from the database.

   See A lso: For other DBA-related considerations, see C hapter 13, "Performing DBA Functions Under Oracle Label Security".

3. Similarly, database users granted the Oracle9i EXEMPT ACCESS POLICY privileg e, either directly or through a database role, are exempt from some Oracle Label Security policy enforcement controls -- READ_CONTROL and CHECK_CONTROL -- regardless of the export mode, application or utility used to access the database or update its data. (See Table 8-2, "Policy Enforcement Options".) The following policy e nforcement 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 a re applied except READ_CONTROL and CHECK_CONTROL.

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

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

Viewing Policy Options on Tables and Schemas

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

• DBA_SA_TABLE_POLIC IES
• DBA_SA_SCHEMA_POLICIES

Using a Labeling Function

Application developers can create labeling functions. These programs can compute and return a la bel using a wide array of resources, including context variables (such as date or username) and data values.

• Labeling Data Rows under Oracle Label Security
• Understanding Labeling Functions in Oracle Label Security Policies
• Creating a Labeling Function for a Policy
• Specifying a Labeling Function in a Policy

Labeling Data Ro ws under Oracle Label Security

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

• Explicitly specify a label in every INSERT or UPDATE to the table.
• Set the LABEL_DEFAULT option, which caus es 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 invoked upon every INSERT or UPDATE statement and indep endently 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, 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 appropria te label for the row. Then you could insert, into your INSERT or UPDATE statements, the following reference:

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

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

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 ma ny opportunities to use SYS_CONTEXT in this way.

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_l
abel||'E:';
       end if;
       /************* Determine Groups *************/
       i_label := i_label||'D'||to_char(deptno);
return TO_LBAC_DATA_LABEL('
human_resources',i_label);
     End;
     /

The following example uses the sa_demo.gen_emp_label from the example in the previ ous 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 =&
gt; '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);

Inserting Labeled Data Using Po licy Options and Labeling Functions

This section explains how enforc ement options and labeling functions affect the insertion of labeled data.

• Evaluating Enforcement Control Options and INSERT
• Inserting Labels When a Labeling Function is Specified
• Inserting Child Rows into Tables with Declarative Referential Integrity E nabled

Evaluating Enforcement Control Options and INSERT

When you a ttempt 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 author ization, 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, the statement will fail.
• If INSERT_ CONTROL is not active, 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.

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 o f 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, the user can potentially insert a row but not be authorized to see t hat row. You can prevent this situation by specifying the CHECK_CONTROL option in the policy. If this option is active, the new data label is checked against the user's read authorization, and if she cannot read it, she will not be able to perform the insert.

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 t he parent row be visible. The user must be able to see the parent row for the insert to succeed, i.e., the user must have read access to the parent row.

If READ_CONTROL is active on the parent table, the user's read authoriz ation must be sufficient to authorize a SELECT on the parent row. For example, a user who cannot read department 20 cannot insert chi ld rows for department 20. (Note that all records will be visible if the user has FULL or READ privilege on the table or schema.)

Updating Lab eled Data Using Policy Options and Labeling Functions

The rules for updates in Oracle Label Security are almost identical to those for inserts, as long as the user is authorized to change the rows in q uestion. This section contains these topics:

• Updating Labels Using CHAR_TO_LABEL
• Evaluating Enforcement Control Options and UPDATE
• Updating Labels When a Labeling Function Is Specified
• Updating Child Rows in Tables with Declarative Referential Integrity Enabled

Updating Labels Using CHAR_TO_LABE L

If you need to change a row's label from SENSITIVE to CONFIDENTIAL , 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';

Evaluating Enforcemen t Control Options and UPDATE

When you attempt to update data based o n 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, an error is raised. Assume, for e xample, 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, the statement will fail.
• If UPDATE_CONTROL is not active, you can update all rows to which you have read access.
• If LABEL_UPDATE is acti ve, you must have the appropriate privilege (WRITEUP, WRITEDOWN, or WRITEACROSS) to change a label by raising or lowering its sensiti vity 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, you can only writ e labels you are authorized to read.

The following figure illustrates the label evalu ation process for LABEL_UPDATE.

Figure 8-1 Label Evaluation Process for LABEL_UPDATE

Text description of the illustration olsag031.gif

A labeling function takes precedence over labe ls 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 activ e labeling function, if present.

Note that the security administrator can establish a label ing 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, you can u pdate a row, but not be authorized to see the row. If the CHECK_CONTROL option is on, you will not be able to perform such an update. CHECK_CONTROL verifies your read authorization on the new label.