Release 2 (9.2)
Part Number A96578-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle Label Security Administrator's Guide Release 2 (9.2) Part Number A96578-01 |
|
This chapter explains how to use Oracle Label Security features to manage labeled data. It then shows how to view and change the value of security attributes for a session. The chapter contains these sections:
This section contains these topics:
Labels defined in Oracle Label Security have an associated label tag that uniquely identifies the label in the database. The label tag can be manually specified by the administrator at the time the label is created, or it will be automatically generated when the label is created.
The label tag (rather than the character-string label value) is stored in the policy-specific label column that is added when an Oracle Label Security policy is applied to a table. By default, the datatype of the policy label column is NUMBER; it is used to store the numeric label tag.
The administrator can specify whether or not to display the column. If he or she applies the HIDE option to a table, then the policy label column is not displayed when a user executes SELECT *, or performs a DESCRIBE. If the policy label column is not hidden, then it is displayed as datatype NUMBER.
SQL> describe emp; Name Null? Type ----------------------------------------- -------- -------- EMPNO NOT NULL NUMBER(4) ENAME CHAR(10) JOB CHAR(9) MGR NUMBER(4) SAL NUMBER(7,2) DEPTNO NOT NULL NUMBER(2) HR_LABEL NUMBER(10)
Notice that in this example, the HR_LABEL column is not displayed.
SQL> describe emp; Name Null? Type ----------------------------------------- -------- -------- EMPNO NOT NULL NUMBER(4) ENAME CHAR(10) JOB CHAR(9) MGR NUMBER(4) SAL NUMBER(7,2) DEPTNO NOT NULL NUMBER(2)
As noted in Chapter 2, the administrator first defines a set of label components to be used in a policy. When the administrator creates labels, he or she specifies the set of valid combinations of components which can make up a label. For each such valid label, an associated numeric tag uniquely identifies the label within the policy.
The label tag can be manually defined by the administrator, to control the ordering of label values when they are sorted or logically compared. If the tag is not pre-defined before a label is used, then a tag is automatically generated for each label as it is used.
Label tags must be unique across all policies in the database. When you use multiple policies in a database, you cannot use the same numeric label tag in different policies. Remember that the label tag is the unique identifier of a label. The data rows do not store the label's character-string representation; rather, they store the label tag.
This section contains these topics:
By manually defining label tags, the administrator can implement a data manipulation strategy which permits labels to be meaningfully sorted and compared. To do this, the administrator pre-defines all of the labels to be associated with protected data, and assigns to each label a meaningful label tag value. Manually assigned label tags can have up to 8 digits. The value of a label tag must be greater than zero.
It may be advantageous to implement a strategy in which label tag values are related to the numeric values of label components. In this way, you can use the tags to group data rows in a meaningful way. This approach, however, is not mandatory. It is good practice to set tags for labels of higher sensitivity to a higher numeric value than tags for labels of lower sensitivity.
Table 4-1 illustrates a set of label tags which have been assigned by an administrator. Notice that in this example the administrator has based the label tag value on the numeric form of the levels, compartments, and rows which were discussed in Chapter 2 (Table 2-2, Table 2-3, and Table 2-4).
| Label Tag | Label String |
|---|---|
|
10000 |
P |
|
20000 |
C |
|
21000 |
C:FNCL |
|
21100 |
C:FNCL,OP |
|
30000 |
S |
|
31110 |
S:OP:WR |
|
40000 |
HS |
|
42000 |
HS:OP |
In this example, labels with a level of PUBLIC begin with "1", labels with a level of CONFIDENTIAL begin with "2", labels with a level of SENSITIVE begin with "3", and labels with a level of HIGHLY_SENSITIVE begin with "4". Labels with the FINANCIAL compartment then come in the 1000 range, labels with the compartment OP are in the 1100 range, and so on. The tens place is used to indicate the group WR, for example. Another strategy might be completely based on groups, where the tags might be 3110, 3120, 3130, and so on. Note, however, that label tags identify the whole label, independent of the numeric values assigned for the individual label components.
An administratively defined label tag can serve as a convenient way to reference a complete label string (that is, a particular combination of label components). As illustrated in Table 4-1, for example, the tag "31110" could stand for the complete label string "S:OP:WR".
Label tags can be used as a convenient way to partition data. For example, all data with labels in the range 1000 - 1999 could be placed in tablespace A, all data with labels in the range 2000 - 2999 could be placed in tablespace B, and so on.
This simplified notation also comes in handy when there is a finite number of labels, and you need to perform various operations upon them. Consider a situation in which one company hosts a human resources system for many other companies. Assume that users from Company Y all have the label "C:ALPHA:CY", for which the tag "210" has been set. To determine the total number of application users from Company Y, the host administrator can enter:
SELECT * FROM tab1 WHERE hr_label = 210;
Dynamically generated label tags, illustrated in Table 4-2 , have 10 digits. In this case there is no relationship at all between the label tag and the numbers assigned to the various label components, nor is there any other means of grouping the data by label.
| Label Tag | Label String |
|---|---|
|
100000020 |
P |
|
100000052 |
C |
|
100000503 |
C:FNCL |
|
100000132 |
C:FNCL,OP |
|
100000003 |
S |
|
100000780 |
S:OP:WR |
|
100000035 |
HS |
|
100000036 |
HS:OP |
When you retrieve labels, you do not automatically obtain the character string value. By default, the label tag value is returned. Two label manipulation functions enable you to convert the label tag value to and from its character string representation:
Use the CHAR_TO_LABEL function to convert a character string to a label tag. This function returns the label tag for the specified character string.
Syntax:
FUNCTION CHAR_TO_LABEL ( policy_name IN VARCHAR2, label_string IN VARCHAR2) RETURN NUMBER;
Example:
INSERT INTO emp (empno,hr_label) VALUES (999, CHAR_TO_LABEL('HR','S:A,B:G5');
Here, "HR" is the label's policy name.
When you query a table or view, you automatically retrieve all of the rows in the table or view that satisfy the qualifications of the query and are dominated by your label. If the policy label column is not hidden, then the label tag value for each row is displayed. You must use the LABEL_TO_CHAR function to display the character string value of each label.
Note that all conversions must be explicit. There is no automatic casting to and from tag and character string representations.
Syntax:
FUNCTION LABEL_TO_CHAR ( label IN NUMBER) RETURN VARCHAR2;
To retrieve the label of a row from a table or view, specify the policy label column in the SELECT statement as follows:
SELECT label_to_char (hr_label) AS label, ename FROM tab1; WHERE ename = 'RWRIGHT';
This statement returns the following:
LABEL ENAME ------------ ---------- S:A,B:G1 RWRIGHT
You can also specify the policy label column in the WHERE clause of a SELECT statement. The following statement displays all rows which have the policy label "S:A,B:G1".
SELECT label_to_char (hr_label) AS label,ename FROM emp WHERE hr_label = char_to_label ('HR', 'S:A,B:G1');
This statement returns the following:
LABEL ENAME ------------- --------- S:A,B:G1 RWRIGHT S:A,B:G1 ESTANTON
Alternatively, you could use a more flexible statement to look up data that contains the string "S:A,B:G1" anywhere in the text of the HR_LABEL column:
SELECT label_to_char (hr_label) AS label,ename FROM emp WHERE label_to_char (hr_label) like '%S:A,B:G1%';
If you do not use the LABEL_TO_CHAR function, you will see the label tag.
The following example is with the numeric column datatype (NUMBER) and dynamically generated label tags, but without using the LABEL_TO_CHAR function. If you do not use the LABEL_TO_CHAR function, you will see the label tag.
SQL> select empno, hr_label from emp where ename='RWRIGHT'; EMPNO HR_LABEL ---------- ---------- 7839 1000000562
If the policy label column is hidden, then it is not automatically returned when you select all columns from a table using the SELECT * command. You must explicitly specify that you want to retrieve the label. For example, to retrieve all columns from the DEPT table (including the policy label column in its character representation), enter the following:
SQL> column label format a10 SQL> select label_to_char (hr_label) as label, dept.* 2 from dept; LABEL DEPTNO DNAME LOC ---------- --------- -------------- ------------- L1 10 ACCOUNTING NEW YORK L1 20 RESEARCH DALLAS L1 30 SALES CHICAGO L1 40 OPERATIONS BOSTON
By contrast, if you do not explicitly specify the HR_LABEL column, the label is not displayed at all. Note that while the policy column name is on a policy basis, the HIDE option is on a table-by-table basis.
During the processing of SQL statements, Oracle Label Security makes calls to the security policies defined in the database. For SELECT statements, the policy filters the data rows which the user is authorized to see. For INSERT, UPDATE, and DELETE statements, Oracle Label Security permits or denies the requested operation, based on the user's authorizations.
This section contains these topics:
This section describes techniques of using numeric label tags in WHERE clauses of SELECT statements.
When using labels in the NUMBER format, the administrator can set up labels such that a list of their label tags distinguishes the different levels. Comparisons of these numeric label tags can be used for ORDER BY processing, and with the logical operators.
For example, if the administrator has assigned all UNCLASSIFIED labels to the 1000 range, all SENSITIVE labels to the 2000 range, and all HIGHLY_SENSITIVE labels to the 3000 range, then you can list all SENSITIVE records by entering:
SELECT * FROM emp WHERE hr_label BETWEEN 2000 AND 2999;
To list all SENSITIVE and UNCLASSIFIED records, you can enter:
SELECT * FROM emp WHERE hr_label <3000;
To list all HIGHLY_SENSITIVE records, you can enter:
SELECT * FROM emp WHERE hr_label=3000;
Alternatively, you can use dominance relationships to set up an ordering strategy.
You can perform an ORDER BY referencing the policy label column to order rows by the numeric label tag value which the administrator has set. For example:
SELECT * from emp ORDER BY hr_label;
Notice that no functions were necessary in this statement. The statement simply made use of label tags set up by the administrator.
|
Note: Again, such queries only have meaning if the administrator has applied a numeric ordering strategy to the label tags originally assigned to the labels. |
Using the LABEL_TO_CHAR function, you can order data rows by the character representation of the label. For example, the following statement returns all rows sorted by the text order of the label:
SELECT * FROM emp ORDER BY label_to_char (hr_label);
This section describes the Oracle Label Security functions which determine the least upper bound or the greatest lower bound of two or more labels. Two single-row functions operate on each row returned by a query; they return one result for each row.
The LEAST_UBOUND (LUBD) function returns a character string label that is the least upper bound of label1 and label2: that is, the one label which dominates both. The least upper bound is the highest level, the union of the compartments in the labels, and the union of the groups in the labels. For example, the least upper bound of HIGHLY_SENSITIVE:ALPHA and SENSITIVE:BETA is HIGHLY_SENSITIVE:ALPHA,BETA.
Syntax:
FUNCTION LEAST_UBOUND ( label1 IN NUMBER, label2 IN NUMBER) RETURN VARCHAR2;
The LEAST_UBOUND function is useful when joining rows with different labels, because it provides a high water mark label for joined rows.
The following query compares each employee's label with the label of his or her department, and returns the higher label--whether it be in the EMP table or the DEPT table.
SELECT ename,dept.deptno, LEAST_UBOUND(emp.hr_label,dept.hr_label) as label FROM emp, dept WHERE emp.deptno=dept.deptno;
This query returns the following:
ENAME DEPTNO LABEL ---------- --------- ---------- KING 10 L3:M:D10 BLAKE 30 L3:M:D30 CLARK 10 L3:M:D10 JONES 20 L3:M:D20 MARTIN 30 L2:E:D30
The GREATEST_LBOUND (GLBD) function can be used to determine the lowest label of the data that can be involved in an operation, given two different labels. It returns a character string label that is the greatest lower bound of label1 and label2. The greatest lower bound is the lowest level, and the intersection of the compartments in the labels and the groups in the labels. For example, the greatest lower bound of HIGHLY_SENSITIVE:ALPHA and SENSITIVE is SENSITIVE.
Syntax:
FUNCTION GREATEST_LBOUND ( label1 IN NUMBER, label2 IN NUMBER) RETURN VARCHAR2;
The MERGE_LABEL function is a utility for merging two labels together. It accepts the character string form of two labels, and the three-character specification of a merge format. Its syntax is as follows:
Syntax:
FUNCTION merge_label (label1 IN number, label2 IN number, merge_format IN VARCHAR2) RETURN number;
The valid merge format is specified with a three-character string:
<highest level or lowest level><union or intersection of compartments><union or intersection of groups>
The following table defines the MERGE_LABEL format constants.
For example, HUI specifies the highest level of the two labels, union of the compartments, intersection of the groups.
The MERGE_LABEL function is particularly useful to developers if the LEAST_UBOUND function does not provide the intended result. The LEAST_UBOUND function, when used with two labels containing groups, may result in a less sensitive data label than expected. The MERGE_LABEL function enables you to compute an intersection on the groups, instead of the union of groups which is provided by the LEAST_UBOUND function.
For example, if the label of one data record contains the group UNITED_STATES, and the label of another data record contains the group UNITED_KINGDOM, and the LEAST_UBOUND function is used to compute the least upper bound of these two labels, the resulting label would be accessible to users authorized for either the UNITED_STATES or the UNITED_KINGDOM.
If, by contrast, the MERGE_LABEL function is used with a format clause of HUI, the resulting label would contain the highest level, the union of the compartments, and no groups--because UNITED_STATES and UNITED_KINGDOM do not intersect.
When you insert data into a table protected by Oracle Label Security, you must specify a value for the label in any INSERT statement (unless the LABEL_DEFAULT policy option is set, or a label function exists to compute the label). To do this, you must explicitly specify the label tag value for the desired label, or explicitly convert the character string representation of the label into the appropriate label tag. Note that this does not mean generating label tags, but simply referencing the appropriate one.
This section explains the different ways to insert labeled data:
| See Also:
Chapter 8, "Applying Policies to Tables and Schemas" for information about inserting data with a labeling function, and updating and deleting labeled data |
To insert a row label, you can specify the label character string, and then transform it into a label using the CHAR_TO_LABEL function. The following example shows how to insert data with explicit labels:
INSERT INTO emp (ename,empno,hr_label) VALUES ('ESTANTON',10,char_to_label ('HR', 'SENSITIVE'));
You can insert data using the numeric label tag value of a label, rather than using the CHAR_TO_LABEL function. For example, if the numeric label tag for SENSITIVE is 3000, it would look like this:
INSERT INTO emp (ename, empno, hr_label) VALUES ('ESTANTON', 10, 3000);
If LABEL_DEFAULT is set, or there is a labeling function applied to the table, you do not need to specify a label in your INSERT statements. The label will be provided automatically. Thus you could enter:
INSERT INTO emp (ename, empno) VALUES ('ESTANTON', 10);
The resulting row label is set according to the default value, or labeling function.
If the label column is hidden, the existence of the column is transparent to the insertion of data. INSERT statements can be written which do not explicitly list the table columns, and do not include a value for the label column. The session's row label or a label function (if provided) is used to label the data.
You can insert into a table without explicitly naming the columns--as long as you specify a value for each non-hidden column in the table. The following example shows how to insert a row into the table described in "Example 2: Numeric Column Datatype with Hidden Column":
INSERT INTO emp VALUES ('196','ESTANTON',Technician,RSTOUT,50000,10);
Note that if the policy label column is not hidden, you must explicitly include a label value (possibly a null value) in the INSERT statement.
If you are generating new labels dynamically as you insert data, you can use the TO_DATA_LABEL function to guarantee that this produces valid data labels. To do this you must have EXECUTE authority on the TO_DATA_LABEL function.
Whereas the CHAR_TO_LABEL function requires that the label already be an existing data label for the transaction to succeed, the TO_DATA_LABEL does not have this requirement. It will automatically create a valid data label.
For example:
INSERT INTO emp (ename, empno, hr_label) VALUES ('ESTANTON', 10, to_data_label ('HR', 'SENSITIVE'));
|
Note: The TO_DATA_LABEL function must be explicitly granted to individuals, in order to be used. Its usage should be tightly controlled. |
| See Also:
Chapter 8, "Applying Policies to Tables and Schemas" for more information about inserting, updating, and deleting labeled data |
During a given session, a user can change his or her labels, within the authorizations set by the administrator.
This section contains these topics:
The following functions enable the user to change the session and row labels:
Use the SET_LABEL procedure to set the label of the current database session.
Syntax:
PROCEDURE SET_LABEL (policy_name IN VARCHAR2, label IN VARCHAR2);
|
policy_name |
The name of an existing policy |
|
label |
The value to set as the label |
A user can set the session label to:
Note that if you change the session label, this change may affect the value of the session's row label. The session's row label contains the subset of compartments and groups for which the user has write access. This may or may not be equivalent to the session label. For example, if you use the SA_SESSION.SET_LABEL command to set your current session label to C:A,B:US and you have write access only on the A compartment, then your row label would be set to C:A.
Use the SET_ROW_LABEL procedure to set the default row label value for the current database session. The compartments and groups in the label must be a subset of compartments and groups in the session label to which the user has write access. When the LABEL_DEFAULT option is set, this row label value is used on insert if the user does not explicitly specify the label.
Syntax:
PROCEDURE SET_ROW_LABEL (policy_name IN VARCHAR2, row_label IN VARCHAR2);
|
policy_name |
The name of an existing policy |
|
row_label |
The value to set as the default row label |
If the SA_SESSION.SET_ROW_LABEL procedure is not used to set the default row label value, then this value is automatically derived from the session label. It contains the level of the session label, and the subset of compartments and groups in the session label for which the user has write authorization.
The row label is automatically reset if the session label changes. For example, if you change your session level from HIGHLY_SENSITIVE to SENSITIVE, the level component of the row label automatically changes to SENSITIVE.
The user can set the row label independently, but only to include:
If the user tries to set the row label to an invalid value, the operation is not permitted, and the row label value is unchanged.
The RESTORE_DEFAULT_LABELS procedure restores the session label and row label to those stored in the data dictionary. This command is useful to reset values after a SA_SESSION.SET_LABEL command has been executed.
Syntax:
PROCEDURE RESTORE_DEFAULT_LABELS (policy_name in VARCHAR2);
|
policy_name |
The name of an existing policy |
The SAVE_DEFAULT_LABELS procedure stores the current session label and row label as your initial session label and default row label. It permits you to change your defaults to reflect your current session label and row label. The saved labels will be used as the initial default settings for future sessions.
Syntax:
PROCEDURE SAVE_DEFAULT_LABELS (policy_name in VARCHAR2);
|
policy_name |
The name of an existing policy |
When you log into a database, your default session label and row label are used to initialize the session label and row label. When the administrator originally authorized your Oracle Label Security labels, he or she also defined your default level, default compartments, and default groups. If you change your session label and row label, and want to save these values as the default labels, you can use the SA_SESSION.SAVE_DEFAULT_LABELS procedure.
This procedure is useful if you have multiple sessions and want to be sure that all additional sessions have the same labels. You can save the current labels as the default, and all future sessions will have these as the initial labels.
Consider a situation in which you connect to the database through Oracle Forms, and want to run a report. By saving the current session labels as the default before you invoke Oracle Reports, you ensure that Oracle Reports will initialize at the same labels as are being used by Oracle Forms.
|
Note: The SA_SESSION.SAVE_DEFAULT_LABELS procedure overrides the settings established by the administrator. |
You can use SA_SESSION functions to view the policy attributes for a session.
You can display security attribute values by using the USER_SA_SESSION view. Access to this view is PUBLIC. It lets you see the security attributes for your current session. For example:
Name Null? Type ----------------------------------------- -------- ------------- POLICY_NAME NOT NULL VARCHAR2(30) SA_USER_NAME VARCHAR2(4000) PRIVS VARCHAR2(4000) MAX_READ_LABEL VARCHAR2(4000) MAX_WRITE_LABEL VARCHAR2(4000) MIN_LEVEL VARCHAR2(4000) LABEL VARCHAR2(4000) COMP_WRITE VARCHAR2(4000) GROUP_WRITE VARCHAR2(4000)
ROW_LABEL VARCHAR2(4000)
The SA_SESSION functions take a policy_name as the only input parameter. They return VARCHAR2 character string values for use in SQL statements.
For example, the following statement shows the current session label for the Human Resources policy:
SQL> select sa_session.label ('human_resources') 2 from dual; SA_SESSIONs.LABEL('HUMAN_RESOURCES') --------------------------------------------- L3:M,E
| See Also:
"Using SA_UTL Functions to Set and Return Label Information" for additional functions that return numeric label tags and BOOLEAN values |
|
 Copyright © 2000, 2002 Oracle Corporation. All Rights Reserved. |
|
