Oracle Label Security, Part 3: Administration - Page 2

October 16, 2003

Determining User Session Label Permissions

With these rules in hand, it is time to turn my attention to the issues encountered when I attempted to insert a new row using the RGNMGR1 user account. When I run the query in Listing 1.1 from the OLS Administration (LBACSYS) user, I can view all the OLS attributes assigned to all users assigned to the SADM security policy:

             Max          Min          Max          Default      Default
             Read         Write        Write        Read         Write
User         Label        Label        Label        Label        Label
------------ ------------ ------------ ------------ ------------ ------------
RGNMGR1      CW:SA:NE     CW           CW:SA:NE     CW:SA:NE     CW:SA:NE
RGNMGR2      CW:SA:SE     UN           CW:SA:SE     CW:SA:SE     CW:SA:SE
RGNMGR3      CW:SA:CN     UN           CW:SA:CN     CW:SA:CN     CW:SA:CN
RGNMGR4      CW:SA:SW     UN           CW:SA:SW     CW:SA:SW     CW:SA:SW
RGNMGR5      CW:SA:NW     UN           CW:SA:NW     CW:SA:NW     CW:SA:NW
SALESADM     CW:SA:T      UN           CW:SA:T      CW:SA:T      CW:SA:T
SLSMGR       CW:SA:T      UN           CW:SA:T      CW:SA:T      CW:SA:T

7 rows selected.

(If I wanted to see the OLS attributes for all users assigned to the SADM security policy's levels, compartments, and groups, I could run the queries in Listing 1.2, Listing 1.3, and Listing 1.4, respectively.)

From these query results, I can now see the problem: When I applied the security policy to the RGNMGR1 user account via the SET_USER_LABELS procedure of the SA_USER_ADMIN package, I supplied a NULL value for the default write label. OLS therefore assigned the maximum read level (CW:SA:NE) as the default write label, and that's what OLS applied when I INSERTed the new row. Luckily, OLS provides several methods to overcome this issue.

Choosing Methods For Inserting New Rows

First, though, I will need to connect as the OLS administrator (LBACSYS) and create a new valid group for the European region, otherwise, I will never be able to add the correct label value during insertion. I will also GRANT EXECUTE permissions on the TO_DATA_LABEL function for an upcoming example (see Listing 1.5).

Now to attempt some different INSERT methods. First, I could use the CHAR_TO_LABEL function to insert a new row into SALESADM.SALES_REGIONS (see Listing 1.6):

SQL> CONNECT salesadm/password;
Connected.
SQL> DELETE FROM salesadm.sales_regions WHERE region_id = 6;
0 rows deleted.
SQL> INSERT INTO salesadm.sales_regions (region_id, abbr, description, sadm_lbl)
  2  VALUES(6, 'EUR', 'European', CHAR_TO_LABEL('SADM', 'CW:SA:EU'));
1 row created.
SQL> COMMIT;
Commit complete.

Here's another approach: I could use a numeric tag value (see Listing 1.7):

SQL> CONNECT salesadm/password;
Connected.
SQL> DELETE FROM salesadm.sales_regions WHERE region_id = 6;
1 row deleted.
SQL> INSERT INTO salesadm.sales_regions (region_id, abbr, description, sadm_lbl)
  2  VALUES(6, 'EUR', 'European', 30160);
1 row created.
SQL> COMMIT;
Commit complete.

However, in both these cases, I will end up with a data label that is not necessarily valid, i.e. has not been defined for the OLS security policy. I have another option: I can use the TO_DATA_LABEL function to create a valid data label "on the fly" (see Listing 1.8):

SQL> DELETE FROM salesadm.sales_regions WHERE region_id = 6;
1 row deleted.
SQL> INSERT INTO salesadm.sales_regions (region_id, abbr, description, sadm_lbl)
  2  VALUES(6, 'EUR', 'European', TO_DATA_LABEL('sadm', 'CW:SA:EU'));
1 row created.
SQL> COMMIT;
Commit complete.

However, this is somewhat dangerous, since now the RGNMGR1 user could create any data label value desired, and I would like to keep my data labels nice and tidy. To prevent this, I can also temporarily change the default label for the RGNMGR1's user session.

Modifying User Session Label Permissions

OLS supplies several functions to allow a user to change her session attributes using the SA_SESSION package. SA_SESSION.SET_LABEL allows a session user to change his current security level, compartment(s), and group(s) to any valid label to which he has read access. Likewise, SA_SESSION.SET_ROW_LABEL allows a session user to set the default row label that will be applied to any new rows inserted into an OLS-secured table. Here is the result of applying changes to RGNMGR1's current user session (see Listing 1.9):

SQL> BEGIN
  2     SA_SESSION.SET_LABEL('SADM', 'CW:SA:EU');
  3     SA_SESSION.SET_ROW_LABEL('SADM', 'CW:SA:EU');
  4  END;
  5  /

PL/SQL procedure successfully completed.

SQL> 
SQL> COL sa_user_name FORMAT A12 HEADING 'User Name'
SQL> COL label        FORMAT A20 HEADING 'Default Label'
SQL> COL row_label    FORMAT A12 HEADING 'Row Label'
SQL> SELECT
  2      sa_user_name
  3     ,label
  4     ,row_label
  5    FROM user_sa_session
  6  ;

User Name    Default Label        Row Label                                     
------------ -------------------- ------------                                  
RGNMGR1      CW:SA:EU             CW:SA:EU                                      

SA_SESSION.RESTORE_DEFAULT_LABELS and SA_SESSION.SAVE_DEFAULT_LABELS allow a session user to restore and save default label values, respectively. See Listing 1.10 for an example of how these procedures work.

SQL> BEGIN
  2     SA_SESSION.RESTORE_DEFAULT_LABELS('SADM');
  3  END;
  4  /

PL/SQL procedure successfully completed.

SQL>
SQL> COL sa_user_name FORMAT A12 HEADING 'User Name'
SQL> COL label        FORMAT A20 HEADING 'Default Label'
SQL> COL row_label    FORMAT A12 HEADING 'Row Label'
SQL> SELECT
  2      sa_user_name
  3     ,label
  4     ,row_label
  5    FROM user_sa_session
  6  ;

User Name    Default Label        Row Label
------------ -------------------- ------------
RGNMGR1      CW:SA:NE,EU          CW:SA:NE,EU

Oracle Policy Manager: A Sharp Blade To Cut Through OLS Confusion

I have found Oracle Policy Manager to be an excellent graphical tool to view the OLS information I have set up for these test cases. Though I'm more in favor of using PL/SQL scripts to accomplish the goal of setting up an OLS security policy, Policy Manager's intuitive interface lets me view and maintain all OLS security policy components, data labels, and user session assignments, as well as which portions of the security policy have been applied to which schema objects.

While a discussion of the myriad uses of Policy Manager is beyond the scope of this article, I have captured some screen images in Listing 2 that reflect the contents of the SALESADM security policy and its application to users and objects.

Conclusion

I have delved more deeply into what happens behind the scenes when a user session attempts to read and write rows that are under the control of OLS, and how to manage the user session labels to get the correct security label values applied to the rows. In my next article, I will cover some additional methods for managing the addition of how to use a label function to apply row label security to rows automatically. I will also supply some additional concrete examples on how to manage OLS security policy components.

References and Additional Reading

While there is no substitute for direct experience, reading the manual is not a bad idea, either. I have drawn upon the Oracle documentation Oracle Label Security Administrator's Guide (A96578-01) for the deeper technical details of this article.

» See All Articles by Columnist Jim Czuprynski