Label Example

Examples are the best tools for illustrating how technology works. I’ve found that the more complex the technology, the simpler the example needs to be. This allows you to better focus on the technology rather than trying to figure out the semantics of column names and the complicated relationships between data structures. Once the technology principles are understood, you should be able to cast this example onto your specific data structures and applications.

The example application presented here represents a bulletin board for displaying announcements, alerts, and other critical information to employees. The data for this bulletin board will be separated and tailored to individual employees based on their need to know.

The users’ need to know, or what they are authorized to see, is derived from their seniority, role, and geographical location.

The application table will reside in the SCOTT schema, and the security will be managed from the SEC_MGR schema. This reflects the fact that the data tables often reside in one schema while the security is enforced from a different schema. The data table will contain multiple simple messages. OLS will ultimately ensure only the relevant messages are viewable by the appropriate parties. Therefore, the table requires only the single column to hold the announcement messages:

scott@KNOX10g> CREATE TABLE announcements    2  (MESSAGE     VARCHAR2(4000)); Table created.

Creating the Policy

Before you begin to create labels, you need to create a security policy. A policy is the container for everything—the labels, user authorizations, and the protected objects. Unlike Trusted Oracle, which applied one set of security labels across all database objects, OLS allows you to create multiple policies and apply the labels to only selected users and objects. When you create the policy, you have to define the name of the column that will be used to hold your labels. You can optionally provide any default security enforcement options.

The policy for this example will store the labels in a column called ROWLABEL, and OLS will place the security label values in the ROWLABEL column. The choice for your column is important because the column name will be appended to the tables on which you want to enforce your OLS policies. Also, the label column name has to be unique among all the OLS policies in your database. Any additional policies you create will have to use a different column name for the label column.

OLS can be managed two ways. The Oracle Policy Manager provides an easy-to-use graphical interface for administering OLS. Alternatively, OLS provides a set of PL/SQL APIs. This example uses APIs to perform the OLS actions. Snapshots from the Policy Manager will be taken periodically to depict how these actions or the results of the actions are graphically represented. An advantage to the PL/SQL calls is that the PL/SQL code can be saved and replayed at a later time if desired. This is advantageous if you need to rebuild your policies or want to replicate your OLS security across several databases.

Create the OLS policy (ESBD, or Effective Security By Design, for this example) by invoking the SA_SYSDBA.CREATE_POLICY procedure. Privileges to execute this procedure have been granted to the default OLS administrator known as LBACSYS.

lbacsys@KNOX10g> BEGIN   2    sa_sysdba.create_policy   3                         (policy_name    => 'ESBD',   4                          column_name    => 'rowlabel');   5  END;   6  / PL/SQL procedure successfully completed.

Note the default OLS installation leaves the LBACSYS account locked and the password expired. The default password is LBCASYS; the password expiration forces you to change it on the initial logon. Choose a strong password because the account has significant database privileges and a compromise of LBACSYS could be disastrous.

When a policy is created, Oracle automatically creates an administrator database role for the policy. The role name is the policy’s name appended with “_DBA”. For the ESBD policy created above, the role name is ESBD_DBA. This role and the privileges granted to it will be used for this example. When you grant the ESBD_DBA role to the SEC_MGR schema, you’re bestowing administration privileges for the ESBD policy to the SEC_MGR user:

lbacsys@KNOX10g> -- Privs and authorization to administer the ESBD policy lbacsys@KNOX10g> GRANT esbd_dba TO sec_mgr; Grant succeeded.

Viewing the results of the policy creation in Figure 12-1, you see that the policy was created, the column defined to hold the label (ROWLABEL), and the policy default status enabled. The Hide Policy Column check box is grayed out because once the policy is created, this option can’t be changed. You’ll see a workaround to this in the upcoming “Changing the Hidden Status” section.

Figure 12-1: A policy can be easily created by executing the PL/SQL package or utilizing the Oracle Policy Manager.

Least Privileges for OLS Administrators

The SEC_MGR will also require the execute privileges on several OLS-related programs. The details of what operations the programs perform are discussed throughout the example as they are used. Note that, in spite of the name, OLS doesn’t grant all privileges necessary for performing all OLS administration tasks to the <policy_name>_DBA role. This was consciously done to allow for further separation of duties for OLS policy administrators. OLS controls who can manage the OLS policy and then further controls what specific actions they can take while managing the policy. In this example, the SEC_MGR will perform all the OLS administration duties. The following privileges are therefore required:

lbacsys@KNOX10g> -- Privs to create components that make up valid labels lbacsys@KNOX10g> GRANT EXECUTE ON sa_components  TO sec_mgr; Grant succeeded. lbacsys@KNOX10g> -- Privileges to create the valid labels lbacsys@KNOX10g> GRANT EXECUTE ON sa_label_admin TO sec_mgr; Grant succeeded. lbacsys@KNOX10g> -- Privileges to assign authorization labels to users lbacsys@KNOX10g> GRANT EXECUTE ON sa_user_admin  TO sec_mgr; Grant succeeded. lbacsys@KNOX10g> -- Privileges to convert a character string to lbacsys@KNOX10g> -- its numeric label representation lbacsys@KNOX10g> GRANT EXECUTE ON char_to_label  TO sec_mgr; Grant succeeded.

OLS makes many interesting and practical uses of the core security capabilities of the database. For example, the role for the policy, ESBD_DBA, is restricted to operations within the specific policy. If you create a new policy and then try to create label components from the SEC_MGR schema, you’ll witness this security control:

lbacsys@KNOX10g> -- Create a new OLS Policy, but don't assign privileges lbacsys@KNOX10g> BEGIN   2    sa_sysdba.create_policy   3                  (policy_name    => 'Different_Policy');   4  END;   5  / PL/SQL procedure successfully completed. lbacsys@KNOX10g> CONN sec_mgr/oracle10g Connected. sec_mgr@KNOX10g> /*** sec_mgr@KNOX10g>   Try to administer the new policy. sec_mgr@KNOX10g>   This will fail because the user does not have role  sec_mgr@KNOX10g>     authorization. sec_mgr@KNOX10g> **/ sec_mgr@KNOX10g> BEGIN   2    sa_components.create_level   3                 (policy_name    => 'Different_Policy',   4                  long_name      => 'foo',   5                  short_name     => 'bar',   6                  level_num      => 9);   7  END;   8  / BEGIN * ERROR at line 1: ORA-12407: unauthorized operation for policy Different_Policy