11 Administering and Using Trusted Stored Program Units

This chapter explains how to use trusted stored program units to enhance system security. It contains these topics:

Introduction to Trusted Stored Program Units
Managing Program Unit Privileges with SET_PROG_PRIVS
Creating and Compiling Trusted Stored Program Units
Using SA_UTL Functions to Set and Return Label Information

11.1 Introduction to Trusted Stored Program Units

Oracle Database stored procedures, functions, and packages are sets of PL/SQL statements stored in a database in compiled form. The single difference between functions and procedures is that functions return a value and procedures do not. Trusted stored program units are like any other stored program units in Oracle Database: the underlying logic is the same.

A package is a set of procedures and functions, together with the cursors and variables they use, stored as a unit. There are two parts to a package, the package specification and the package body. The package specification declares the external definition of the public procedures, functions, and variables that the package contains. The package body contains the actual text of the procedures and functions, as well as any private procedures and variables.

A trusted stored program unit is a stored procedure, function, or package that has been granted one or more Oracle Label Security privileges. Trusted stored program units are typically used to let users perform privileged operations in a controlled manner, or update data at several labels. This is the optimal approach to permit users to access data beyond their authorization.

Trusted stored program units provide fine-grained control over the use of privileges. Although you can potentially grant privileges to many users, the granting of privileges should be done with great discretion because it might violate the security policy established for your application. Rather than assigning privileges to users, you can identify any application operations requiring privileges, and implement them as trusted program units. When you grant privileges to these stored program units, you effectively restrict the Oracle Label Security privileges required by users. This approach employs the principle of least privilege.

For example, if a user with the label CONFIDENTIAL needs to insert data into SENSITIVE rows, then you can grant the WRITEUP privilege to a trusted stored program to which the user has access. In this way, the user can perform the task by means of the trusted stored program, while staying at the CONFIDENTIAL level.

The trusted program unit performs all the actions on behalf of the user. You can thus effectively encapsulate the security policy into a module that can be verified to make sure that it is valid.

11.1.1 How a Trusted Stored Program Unit Runs

A trusted stored program unit runs using its own privileges, and the caller's labels. In this way, it can perform privileged operations on the set of rows constrained by the user's labels.

Oracle Database system and object privileges are intended to be bundled into roles. Users are then granted roles as necessary. By contrast, Oracle Label Security privileges can only be assigned to users or to stored program units. These trusted stored program units provide a more manageable mechanism than roles to control the use of Oracle Label Security privileges.

11.1.2 Trusted Stored Program Unit Example

A trusted stored program unit with the READ privilege can read all unprotected data and all data protected by this policy in the database. Consider, for example, a user who is responsible for creating purchasing forecast reports. The user must perform a summation operation on the amount of all purchases. Regardless of whether or not user's own labels authorize access to the individual purchase orders. The syntax for creating the summation procedure in this example is as follows:

CREATE FUNCTION sum_purchases RETURN NUMBER IS
  psum NUMBER;
BEGIN
  SELECT SUM(amount) INTO psum
  FROM purchase_orders;
RETURN psum;
END sum_purchases;

In this way, the program unit can gather information the end user is not able to gather, and can make it available by means of a summation.

Note that to run SUM_PURCHASES, the user would need to be granted the standard Oracle Database EXECUTE object privilege upon this procedure.

11.2 Managing Program Unit Privileges with SET_PROG_PRIVS

To grant privileges to a stored program unit, you must have the policy_DBA role, and the EXECUTE permission on the SA_USER_ADMIN package. You can use either the SA_USER_ADMIN package or Oracle Enterprise Manager to manage Oracle Label Security privileges.

Use the SA_USER_ADMIN.SET_PROG_PRIVS procedure to set policy-specific privileges for program units. If the privileges parameter is NULL, then the program unit's privileges for the policy are removed.

Syntax:

PROCEDURE SET_PROG_PRIVS (
  policy_name           IN VARCHAR2,
  schema_name           IN VARCHAR2,
  program_unit_name     IN VARCHAR2,
  privileges            IN VARCHAR2);

Parameter	Specifies
policy_name	The policy name of an existing policy
program_unit_name	Specifies the program unit to be granted privileges
privileges	A comma-delimited character string of policy-specific privileges

For example, to give the READ privilege to the SUM_PURCHASES function (described in "Trusted Stored Program Unit Example"), you could enter:

EXECUTE sa_user_admin.set_prog_privs (
'HR','myschema','sum_purchases','READ');

When the SUM_PURCHASES procedure is then called, it runs with the READ privilege as well as the current user's Oracle Label Security privileges. Using this technique, the user can be allowed to find the value of the total corporate payroll, without learning what salary any individual employee receives.

Warning:

When you create a trusted stored program unit, have the Oracle Label Security administrator review it carefully and evaluate the privileges you are granting to it. Ensure, for example, that procedures in trusted packages do not perform privileged database operations and then write result or status information into a public variable of the package. In this way, you can make sure that no violations of your site's Oracle Label Security policy can occur.

11.3 Creating and Compiling Trusted Stored Program Units

This section contains these topics:

Creating Trusted Stored Program Units
Setting Privileges for Trusted Stored Program Units
Recompiling Trusted Stored Program Units
Re-creating Trusted Stored Program Units
Running Trusted Stored Program Units

11.3.1 Creating Trusted Stored Program Units

You create a trusted stored program unit in the same way that you create a standard procedure, function, or package, that is by using the CREATE PROCEDURE, CREATE FUNCTION, or CREATE PACKAGE and CREATE PACKAGE BODY statements. The program unit becomes trusted when you grant it Oracle Label Security privileges.

11.3.2 Setting Privileges for Trusted Stored Program Units

When a developer creates a stored program unit, the Oracle Label Security administrator can verify the correctness of the code before granting the necessary privileges to the stored program unit. Whenever the trusted stored program unit is re-created or replaced, its privileges are removed. The Oracle Label Security administrator must then verify the code again and grant the privileges once again.

11.3.3 Recompiling Trusted Stored Program Units

Recompiling a trusted stored program unit, either automatically or manually (using ALTER PROCEDURE), does not affect its Oracle Label Security privileges. You must, however, grant the EXECUTE privilege on the program unit again after recompiling.

11.3.4 Re-creating Trusted Stored Program Units

Oracle Label Security privileges are revoked if you perform a CREATE OR REPLACE operation on a trusted stored program unit. This limits the potential for misuse of a procedure's Oracle Label Security privileges. Note that the procedure, function, or package can still run even if the Oracle Label Security privileges have been removed.

If you re-create a procedure, function, or package, then you should carefully review its text. When you are certain that the re-created program unit does not violate your site's Oracle Label Security policy, you can then grant it the required privileges again.

In a development environment where trusted stored program units must frequently be replaced (for example, during the first few months of a live system), it is advisable to create a script that can grant the proper Oracle Label Security privileges, as required.

11.3.5 Running Trusted Stored Program Units

Under Oracle Label Security all the standard Oracle Database controls on procedure call (regarding access to tables and schemas) are still in force. Oracle Label Security complements these security mechanisms by controlling access to rows. When a trusted stored program unit is carried out, the policy privileges in force are a union of the invoking user's privileges and the program unit's privileges. Whether a trusted stored program unit calls another trusted program unit or a non-trusted program unit, the program unit called runs with the same privileges as the original program unit.

If a sequence of non-trusted and trusted stored program units is carried out, the first trusted program unit will determine the privileges of the entire calling sequence from that point on. Consider the following sequence:

Procedure A (non-trusted)
Procedure B with WRITEUP
Procedure C with WRITEDOWN
Procedure D (non-trusted)

Here, Procedures B, C, and D all runs with the WRITEUP privilege, because B was the first trusted procedure in the sequence. When the sequence ends, the privilege pertaining to Procedure B is no longer in force for subsequent procedures.

Note:

Unhandled exceptions raised in trusted program units are caught by Oracle Label Security. This means that error messages may not be displayed to the user. For this reason, you should always thoroughly test and debug any program units before granting them privileges.

11.4 Using SA_UTL Functions to Set and Return Label Information

The SA_UTL package provides several functions for use within PL/SQL programs. These functions return information about the current values of the session security attributes, in the form of numeric label values. Although they can be used in program units that are not trusted, these functions are primarily for use in trusted stored program units.

Note that these are public functions; you do not need the policy_DBA role to use them. In addition, each of the functions has a parallel SA_SESSION function that returns the same labels in character string format.

Viewing Session Label and Row Label Using SA_UTL
Checking Rights to Read and Update Table Row Data
Setting the Session Label and Row Label Using SA_UTL
Returning Greatest Lower Bound and Least Upper Bound

See Also:
"Viewing Session Attributes with SA_SESSION Functions"

11.4.1 Viewing Session Label and Row Label Using SA_UTL

SA_UTL provides the following procedures for viewing session label and row label.

11.4.1.1 SA_UTL.NUMERIC_LABEL

This procedure returns the current session label. It takes a policy name as the input parameter and returns a NUMBER value.

SA_UTL.NUMERIC_LABEL (policy_name) RETURN NUMBER;

11.4.1.2 SA_UTL.NUMERIC_ROW_LABEL

This procedure returns the current row label. It takes a policy name as the input parameter and returns a NUMBER value.

SA_UTL.NUMERIC_ROW_LABEL (policy_name) RETURN NUMBER;

11.4.1.3 SA_UTL.DATA_LABEL

This function returns TRUE if the label is a data label.

FUNCTION DATA_LABEL(label IN NUMBER) 
RETURN BOOLEAN;

11.4.2 Checking Rights to Read and Update Table Row Data

SA_UTL provides the following functions for checking the current session user rights to policy labeled data.

11.4.2.1 SA_UTL.CHECK_READ

Use this function to check if the user can read a policy protected table row. This function returns 1 if the user can read the table row. It returns 0 if the user cannot read the table row. The input values are the policy name and the row data label.

FUNCTION CHECK_READ (
  policy_name     IN VARCHAR2,
  label       IN NUMBER) 
RETURN NUMBER;

Note:

The user should already have read privileges on the table to read any data from the table.

11.4.2.2 SA_UTL.CHECK_WRITE

Use this function to check if the user can insert, update, or delete data in a policy protected table row. This function returns 1 if the user can write to the table row. It returns 0 if the user cannot write to the table row. The input values are the policy name and the row data label.

FUNCTION CHECK_WRITE (
  policy_name     IN VARCHAR2,
  label       IN NUMBER) 
RETURN NUMBER;

Note:

The user should already have update privileges on the table to write any data into the table.

11.4.2.3 SA_UTL.CHECK_LABEL_CHANGE

Use this function to check if the user can change the data label for a policy protected table row. This function returns 1 if the user can change the data label. It returns 0 if the user cannot change the data label. The input values are the policy name, the current data label, and the new data label.

FUNCTION CHECK_LABEL_CHANGE (
  policy_name     IN VARCHAR2,
  current_label   IN NUMBER,
  new_label       IN NUMBER) 
RETURN NUMBER;

Note:

The user should already have update privileges on the table to write any data into the table.

11.4.3 Setting the Session Label and Row Label Using SA_UTL

These procedures use numeric labels instead of character strings as input values. Available SA_SESSION procedures perform the same functions as these, but in character string format.

11.4.3.1 SA_UTL.SET_LABEL

Use this procedure to set the label of the current database session. The session's write label and row label are set to the subset of the label's compartments and groups that are authorized for write access.

PROCEDURE SET_LABEL (policy_name IN VARCHAR2,
                     label IN NUMBER);

Parameter	Specifies
policy_name	The name of an existing policy
label	The label to set as the session label

11.4.3.2 SA_UTL.SET_ROW_LABEL

Use this procedure to set the row label of the current database session. The compartments and groups in the label must be a subset of compartments and groups in the session label that are authorized for write access.

PROCEDURE SET_ROW_LABEL (policy_name IN VARCHAR2,
                         row_label IN NUMBER);

Parameter	Specifies
policy_name	The name of an existing policy
row_label	The label to set as the session default row label

11.4.4 Returning Greatest Lower Bound and Least Upper Bound

Functions for greatest lower bound and least upper bound are available.

11.4.4.1 GREATEST_LBOUND

This function returns a label that is the greatest lower bound of the two label arguments.

Syntax:

FUNCTION GREATEST_LBOUND (label1 IN NUMBER,
                          label2 IN NUMBER)
RETURN NUMBER;

11.4.4.2 LEAST_UBOUND

This function returns an Oracle Label Security label that is the least upper bound of the label arguments.

Syntax:

FUNCTION LEAST_UBOUND (label1 IN NUMBER,
                       label2 IN NUMBER)
RETURN NUMBER;

See Also:

"Determining Upper and Lower Bounds of Labels". The functions described here are the same as those described in Chapter 4, except that these return a number instead of a character string.