Oracle Label Security

Due to the many issues cited in the previous section, customers naturally started asking for the label-based functionality without the strict MAC OS dependence. For databases, this requirement basically meant selective row-level security. Oracle Consulting first responded to this by crafting label-based access control solutions using standard Oracle running on standard operating systems. This could be done because the customer requirements were for row-level security, and their operating environment didn’t force them to use Mandatory Access Controls across the entire system.

Oracle Coporation’s database security product management team recognized the value to the customers and began to build in native support for labeling and what became known as fine-grained access control, or row-level security. The Virtual Private Database (VPD), released with Oracle 8.1.5, enabled many customers and Oracle consulting, to create row-level security solutions by exploiting native capabilities within the database.

Oracle Label Security entered the market as a product with version 8.1.7 but was initially only released on the Sun Solaris platform. With Oracle9i Database, OLS became available on all platforms the database supported. Unlike Trusted Oracle, OLS was developed independent of the operating system on which it ran. This allowed OLS to be supported on all platforms for which Oracle provided a database, as well as all future versions. The version skipping seen with

Trusted Oracle wasn’t repeated with OLS.

How OLS Works

Oracle Label Security (OLS) allows you to define a security policy that is implemented by marking the data records with security labels. The label markings indicate what rights a person must possess in order to read or write the data. The labels are stored with each record in a special column that is added to the table. The database users are also given labels that indicate their access rights to the data records. When the user accesses the table records, the database’s OLS engine compares the user’s label with the row’s label marking to determine if the user can have access.

This is essentially the same model that Trusted Oracle used in its MAC implementation except that OLS isn’t enforced on every database table; it’s applied only to the tables that need row-level security.

OLS also supports multiple security policies, or ways to classify the data. You can create a policy with top secret, secret, and confidential classifications, and you can create another policy with proprietary, company sensitive, and public classifications. There is no limit to the number of security policies or the names and semantics of the labels. The following examples will help you better understand how the policy is created, defined, and applied.

Installing OLS

OLS is one of the few options that isn’t part of the standard Enterprise Edition installation.

To install OLS, you have to choose the Custom Database option with the Oracle Installer and consciously select the Oracle Label Security option. Additionally, you have to choose the tablespace for the OLS option at the appropriate time in the database installation process.

Note 

OLS is not installed with the default Enterprise Edition installation. You must choose the Custom Database installation to install OLS.

If a database has already been installed, you can use the Oracle Installer (selecting a Custom Database) to add the OLS option. You’ll then have to use the Oracle Database Configuration Assistant to install the PL/SQL packages needed to support the OLS functionality. See Appendix C of the Oracle Label Security Administrator’s Guide for more installation information.

Implementing Label Security

There are five steps necessary to implement OLS; each of these steps is discussed in more detail in the code examples later in this chapter.

1. Create the OLS policy. The policy is the container for the labels, user authorizations, and protected database objects.

2. Define the OLS label components. Each label consists of a permutation of three components, which are defined in this step.

3. Create the actual OLS labels you wish to use. You have to define the valid labels for OLS. Take the components defined in step 2 and create a valid set of labels based on your application’s security policy. This step is optional, but it’s generally done to ensure label data integrity.

4. Apply the OLS security policy (labels) to your table(s) or schemas. This adds a label column to the table and adds the infrastructure required to support the row-level security based on the labels. This step also defines the security enforcement behavior of your policy.

5. Assign the label authorizations to be used by the users or applications. This step determines who will ultimately gain access to what. Labels are assigned to “users,” which may be a single user or a group of users. OLS mediates access to data by comparing the user’s label with the label on the data record(s).