VPD Versus Label Security

Another common question that arises is, “When should I use VPD, and when should I use OLS?” Personally, I always try OLS first. In many ways, OLS is an easier tool for creating and managing row-level security. After all, it implements the security code for you.

The answer, however, is dependent on the security policy and how well the data lends itself to labeling. If you can create a labeling policy that is congruent with your security policy, then OLS is definitely the way to proceed. If you work for an intelligence agency, or the Department of Defense, then you should clearly be using OLS because the product was specifically designed for you. Chapter 2 of the Oracle Label Security Administrator’s Guide gives five sample labeling policies that can help serve as a template for creating your very own policy.

Advantages of OLS

Why not let the facts determine the choice for you? OLS provides a GUI (Oracle Policy Manager) to administer and maintain the security. This greatly simplifies the deployment and maintenance of the security solution. The Policy Manager can help non-DBAs understand or possibly audit the security implementation. This supports the separation of duty concept.

OLS also requires zero security code. Coding refers to the implementation of the security policy. The previous examples were not code, rather they were calls to administer the code that implements the labels. No coding required is desirable. Mistakes in security code can be difficult to find and fix.

OLS has been evaluated by independent testing. Oracle spent nearly one million dollars testing OLS under the Common Criteria (ISO 15408) evaluations. The tests were performed by security experts. The conclusion, as given by the EAL4 evaluation, is that OLS sufficiently meets the rigorous security requirements it was designed to meet. Chances are pretty significant that the code you write will not be evaluated with the same amount of rigor.

OLS is an out-of-the-box, no coding required, row-level security solution. Unfortunately, all the world’s security policies can’t be implemented via label based access controls.

Advantages of VPD

One certain fact exists: there is nothing that OLS can do that VPD can’t do. The opposite is not true. There are quite a few things VPD can do that OLS can’t. For example, OLS doesn’t work on views or synonyms. OLS needs a real column of type number to store the labels. (However, OLS can be placed on the underlying tables from which the views will query.)

VPD or views are appropriate when access is user oriented. That is, if the policy restricts access based on who is executing the query and there is a column in the record that maps to this user.

VPD supports partitioned access to tables in which different policies can be dynamically enabled and disabled based on a driving application context. For OLS to emulate this, it would have to enforce multiple policies on the same table, each one adding a policy-specific label column to the table. It’s quite possible the OLS policies would exclude each other, thus rendering the solution ineffective.

New to Oracle 10g VPD is support for column-sensitive row-level security. OLS hasn’t yet inherited this capability.

VPD and OLS

You don’t have to choose OLS or VPD; you can use both. In fact, OLS makes it very easy to add a VPD predicate. The APPLY_TABLE_POLICY procedure accepts a VPD predicate as a parameter. For this example, if you want to restrict message reading to business hours, add a VPD predicate to the existing OLS policy:

sec_mgr@KNOX10G> begin   2    sa_policy_admin.remove_table_policy (   3      policy_name => 'ESBD',   4      schema_name => 'SCOTT',   5      table_name  => 'ANNOUNCEMENTS');   6    sa_policy_admin.apply_table_policy (   7      policy_name   => 'ESBD',   8      schema_name   => 'SCOTT',   9      table_name    => 'ANNOUNCEMENTS',  10      table_options => 'HIDE,LABEL_DEFAULT,LABEL_UPDATE,' ||  11                       'WRITE_CONTROL,READ_CONTROL',  12      predicate     => 'to_char(sysdate,''D'') not in (1,7)');  13  end;  14  / PL/SQL procedure successfully completed. sec_mgr@KNOX10G> sec_mgr@KNOX10G> conn scott/tiger Connected. scott@KNOX10G> select to_char(sysdate,'D') from dual; T - 6 scott@KNOX10G> select * from total_announcements; TOTAL_MESSAGES --------------             14

Setting the date to Saturday, you can re-execute the query to validate that VPD is working, too:

scott@KNOX10G> select to_char(sysdate,'D') from dual; T - 7 scott@KNOX10G> select * from announcements; no rows selected

This is an excellent solution for security policies that require user-level restrictions. Generally, user-level access isn’t given with OLS, because it would imply that there is a label created for every user. You could do this for up to 10,000 users, at which time you would run out of compartments or groups.

The VPD predicate added to OLS can use application context capabilities, any functions, and anything that VPD can use. Many times the security policy has a part that can be easily done with labels, and a part that isn’t so easy to do with labels. Combining OLS and VPD gives you the best of both worlds.

Policy Predicate Tip

Another great use of the policy predicate is to allow it to function as an easy way to grant access to data for users without specific authorizations. For example, if you wanted all employees to get access to data labeled as EMP, which has a label tag value of three, you could add a predicate as follows:

sec_mgr@KNOX10g> begin   2    sa_policy_admin.remove_table_policy (   3      policy_name => 'ESBD',   4      schema_name => 'SCOTT',   5      table_name  => 'ANNOUNCEMENTS');   6    sa_policy_admin.apply_table_policy (   7      policy_name   => 'ESBD',   8      schema_name   => 'SCOTT',   9      table_name    => 'ANNOUNCEMENTS',  10      table_options => 'HIDE,LABEL_DEFAULT,LABEL_UPDATE,' ||  11                       'WRITE_CONTROL,READ_CONTROL',  12      predicate     => 'OR ROWLABEL = 3');=  13  end;  14  / PL/SQL procedure successfully completed.

This will allow any database user, even ones without any OLS authorizations, to access the EMP data. Using the value of the ROWLABEL instead of the CHAR_TO_LABEL function ensures that this query will execute quickly.

Using this technique, you don’t have to create authorization tags for every user. You could also have specified, OR ROWLABEL is NULL for data that has yet to be labeled for an existing table to which you have just applied an OLS policy and haven’t yet labeled any data.

Note the use of the OR in the predicate above. This tells OLS to apply its policy, or apply your predicate condition. If you do not include an OR, then the predicate is automatically added to the OLS policy enforcement by way of a logical AND. You will find this a very useful feature to augmenting standard OLS capabilities.