| <
strong>Oracle® Label Security Administrator's Guide 10g Release 1 (10.1) Part Number B10774-01 |
|
|
View PDF |
This chapter explains how to
The chapter contains these sections:
This sec tion explains how policy label columns in a table or schema are created and filled, using these topics:
Each policy that is applied to a table creates a column in the database. By default, the datatype of the policy label column is NUMBER.
|
Note: The act of creating a policy does not in itself have any effects on tables or schemas. App lying the policy to a table or schema is what does it. See these sections:
|
Each row's label for that policy is represented by a tag in that column, using the numeric equi valent of the character-string label value. The label tag is automatically generated when the label is created, unless the administra tor specifies the tag manually at that time.
The automatic label generation follows the rul es established by the administrator when he defined the label components, as described in Chapter 2 , "Understanding Data Labels and User Labels".
The administrator can decide not to display the column representing a policy by applying the HIDE option to the table. After a p olicy using HIDE is applied to a table, a user executing a SELECT * or performing a DESCRIBE will not see the policy label column. If the policy label column is not hidden, then the label tag is displayed as datatype NUMBER. See The HID E Policy Column Option.
SQL> describe emp; Name Null? Type ----------------------------------------- -------- -------- EMPNO NOT NULL NUMBER(4) ENAME CHAR(10) < /a> JOB CHAR(9) MGR NUMBER(4) SAL NUMBER(7,2) DEPTNO NOT NULL NUMBER(2) HR_LABEL NUMBER(1 0)
Notice that in th is 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 NUMBE R(2)
As noted in Chapter 2, the administrator first defines a set of label components to be used in a policy. When creating labels, the administrator specifie s the set of valid combinations of components that can make up a label, that is, a level optionally combined with one or more groups or compartments. Each such valid label within a policy is uniquely identified by an associated numeric tag assigned by the administra tor or generated automatically upon its first use. Manual definition has the advantage of allowing the administrator to control the o rdering of label values when they are sorted or logically compared.
However, label tags mus t 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 each label tag uniquely identifies one label, and that numeric tag is what is stored in the data rows, not the label's character-string representation.
This section contains these top ics:
By man ually defining label tags, the administrator can implement a data manipulation strategy that 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 th an zero.
It may be advantageous to implement a strategy in which label tag values are relat ed 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 se t of label tags that have been assigned by an administrator. Notice that in this example the administrator has based the label tag va lue on the numeric form of the levels, compartments, and rows that were discussed in Chapter 2 (Table&nb sp;2-2, Table 2-4, and Table 2-6).
| Label Tag | Label String | ||
|---|---|---|---|
|
10000 |
P | ||
|
20000 |
C | ||
|
21000 td> |
C:FNCL | ||
|
21100 |
C:FNCL,OP | ||
|
30000 |
S | ||
|
31110 |
S:OP:WR |
tr>
||
|
40000 |
HS | ||
|
42000 |
HS:OP |
| Label Tag | Label String |
|---|---|
|
100000020 |
a>
P |
|
100000052 |
C |
|
100000503 |
C:FNCL |
|
100000132 |
C:FNCL,OP |
|
100000003 |
< p class="TB">S |
|
1 00000780 |
S:OP:WR |
|
100000035 |
HS |
|
100 000036 |
HS:OP |
| See Also: |
| LABEL | DEPTNO | DNAME | LOC |
|---|---|---|---|
|
L1 |
10 |
ACCOUNTING |
|
|
L1 |
20 |
RESEARCH |
DALLA S |
|
L1 |
SALES |
CHICAGO | |
|
40 |
OPERATIONS |
BOSTON |
By contrast, if you do not explicitly specify the HR_L ABEL 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 t he processing of SQL statements, Oracle Label Security makes calls to the security policies defined in the database by the create and apply procedures discussed and. For SELECT statements, the pol icy filters the data rows that the user is authorized to see. For INSERT, UPDATE, and DELETE statements, Oracle Label Security permit s or denies the requested operation, based on the user's authorizations.
This section conta ins these topics:
This section describes techniques of using numeric label tags in WHERE clauses of SELECT state ments.
When using labels in the NUMBER format, the administrator can set up labels such tha t a list of their label tags distinguishes the different levels. Comparisons of these numeric label tags can be used for ORDER BY pro cessing, 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, th en you can list all SENSITIVE records by entering:
SELECT * FROM emp WHERE hr_label BETWEEN 2000 AND 2999;
To list all SENSITIVE and U NCLASSIFIED 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;< div align="center">
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 that the administrator has set. For exa mple:
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.
N ote:Again, such queries only have meaning if the administrator has applied a n umeric ordering strategy to the label tags originally assigned to the labels.
Ordering by Character Representatio n of Label
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);< a name="1008755">Determining Upp er and Lower Bounds of Labels
This section describes the Oracle Labe l Security functions that 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.
|
< /a>Note: In all fu nctions that take multiple labels, the labels must all belong to the same policy. |
The LEAST_UBOUND (LUBD) function returns a ch aracter string label that is the least upper bound of label1 and label2: that is, the one label that dominates both. The least upper bound is the highest level, the union of the compartments in the labels, and the unio n of the groups in the labels. For example, the least upper bound of HIGHLY_SENSITIVE:ALPHA and SENSITIVE:BETA is HIGHLY_SENSITIVE:AL PHA,BETA.
Syntax:
F UNCTION LEAST_UBOUND ( label1 IN NUMBER, label2 IN NUMBER) RETURN VARCHAR2;
The LE AST_UBOUND function is useful when joining rows with different labels, because it provides a high water mark label for joined rows. p>
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 enam e,dept.deptno, LEAST_UBOUND(emp.hr_label,dept.hr_label) as label FROM emp, dept WHERE emp.deptno=dept.deptno;
This query retu rns the following data:
| 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) fun ction can be used to determine the lowest label of the data that can be involved in an operation, given two different labels. It retu rns a character string label that is the greatest lower bound of label1 and label2. T he 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 ( l abel1 IN NUMBER, label2 IN NUMBER) RETURN VARCHAR 2;
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 specificati on of a merge format. Its syntax is as follows:
Syntax:
< pre class="CE">FUNCTION merge_label (label1 IN number, label2 IN nu mber, merge_format IN VARCHAR2) RETURN number; a>The valid merge format is specified with a three-character string:
<highest level or lowest level><union or intersection of compartments><unio n or intersection of groups>
The following table defines the MERGE_LABEL format constants.
For example, HUI specifies the highest level of th e two labels, union of the compartments, intersection of the groups.
The MERGE_LABEL functi on 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 enabl es you to compute an intersection on the groups, instead of the union of groups that 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 a nother 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 inters ect.
When you insert data into a table protected by a policy under Oracle Label Security, a numeric label value tag must be supplied, usually in the INSERT statement itself.
To do this, you must explicitly specify the tag for the desired label, or explicitly convert the charact er string representation of the label into the appropriate tag. Note that this does not mean generating new label tags, but simply re ferencing the appropriate one. When Oracle Label Security is using Oracle Internet Directory, the only permissible labels (and corres ponding tags) are those pre-defined by the administrator and already in Oracle Internet Directory.
The only times an INSERT statement may omit a label value are:
In cases a and b, the user's session default row label is used as the inserted row's label. In the c case, the inserted row's label is created by that labeling function.
< div align="center">See Also:
|
This section explains the different ways to specify a label in an INSERT statement:
To insert a row label, you can sp ecify the label character string, and then transform it into a label using the CHAR_TO_LABEL function. Using the definition for table emp, 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 u sing 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 y our INSERT statements. The label will be provided automatically. Thus you could enter:
INSE RT INTO emp (ename, empno) VALUES ('ESTANTON', 10);
The resulting row label is set according to the default value (or by a 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 that do not explicitly list the table columns, and do not include a value for the label column. The session 's row label is used to label the data, or a labeling function is used if one was specified when the policy was applied to the table or schema.
You can insert into a table without explicitly naming the columns--as long as yo u specify a value for each non-hidden column in the table. The following example shows how to insert a row into the table described i n "Example 2: Numeric Column Datatype with Hidden Column":
INSERT INTO emp VALUES ('196','ESTANTON',Technician,RSTOUT,50000,10);
Its label will be one of the following three possibilities:
|
Note: When Oracle Label Security is installed to work with Oracle Internet Directory (OID), dynamic label generation is not allowed, because labels are mana ged centrally in OID, using olsadmintool commands. (See Appendix B, "Command-line Tools for Label Sec urity Using Oracle Internet Directory".) Therefore, when Oracle Label Security is direct ory-enabled, this function, TO_DATA_LABEL, is not available and will generate an error message if used. |
If you are generating new labels dynamically as you insert data, you can use the TO_DATA_LA BEL function to guarantee that this produces valid data labels. To do this you must have EXECUTE authority on the TO_DATA_LABEL funct ion.
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 automaticall y 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 A
lso:
Chapter 9, "Applying Policies to Table s and Schemas" for more information about inserting, updating, and deleting labeled data |
During a given session, a user can chang e his or her labels, within the authorizations set by the administrator.
This section conta ins 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 databas e session.
Syntax:
PROCEDURE SET_LABEL (policy_name IN VARCHAR2, label IN VARCHAR2);
| Specifies |
policy_n ame |
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 lab el 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.
a>Use the SET_ROW_LABEL proce dure to set the default row label value for the current database session. The compartments and groups in the label must be a subset o f compartments and groups in the session label to which the user has write access. When the LABEL_DEFAULT option is set, this row lab el 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);
| Paramet er | Specifies |
|---|---|
|
policy_name |
The name of an existing policy. |
|
label |
The value to set as the default row label |
If the SA_SESSI ON.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: p>
If the user tries to set the row label to an invalid value, the operation is not permitted, and the row label value i s 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 i n VARCHAR2);
where policy_name provides the name of an existing policy.
Syntax:
PROCEDURE SAVE_DEFAULT_LABELS (policy_name in VARCHAR2);
where policy_name provides the name of an existing policy.
When you log into a database, your default session label and row label are used to initialize the sessi on label and row label. When the administrator originally authorized your Oracle Label Security labels, he or she also defined your d efault 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 proc edure 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 s ession labels as the default before you invoke Oracle Reports, you ensure that Oracle Reports will initialize at the same labels as a re being used by Oracle Forms.
|
Note: The SA_SESSION.SAVE_DEFAULT_LABELS procedure overrides the settings established by t he administrator. |
You can use SA_SESSION functions to view the policy attributes for a session.
You can disp lay security attribute values by using the USER_SA_SESSION view. Access to this view is PUBLIC. It lets you see the security attribut es for your current session. For example:
| 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 |
< /a> |
VARCHAR2(4000) |
|
LABEL |
VARCHAR2(4000) | |
|
COMP_WRITE |
VARCHAR2(4000) | |
|
GROUP_WRITE |
< td class="Formal"> | |
|
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.
| Function | < th class="Formal" align="left" valign="bottom" scope="col"> P urpose|
|---|---|
| <
/a>
SA_SESSION.PRIVS |
Returns the set of current sess ion privileges, in a comma-delimited list |
|
SA_SESSION.MIN_LEVEL |
Returns the minimum level authorized for the session |
|
SA_SESSION.MAX_LEVEL |
Returns the maximum level aut horized for the session |
|
SA_SESSION.COMP_READ |
Returns a comma-delimited list of comp artments that the user is authorized to read |
|
SA_SESSION.COMP_WRITE |
Returns a comma- delimited list of compartments that the user is authorized to write. This is a subset of SA_SESSION.COMP_READ. |
|
SA_SESSION.GROUP_READ |
Returns a comma-delimited list of groups that the user is authorized to read |
|
SA_SESSION.GROUP_WRITE |
Returns a comma-delimited list of groups that the user is authoriz ed to write. This is a subset of SA_SESSION.GROUP_READ. |
|
SA_SESSION.LABEL |
Returns th e session label (the level, compartments, and groups) with which the user is currently working. The user can change this value with S A_SESSION.SET_LABEL (see Changing the Session Label with SA_SESSION.SET_LABEL). |
|
SA_SESSION.ROW_LABEL |
Returns the session's default row label value. The user can change this value wi th SA_SESSION.SET_ROW_LABEL (see Changing the Row Label with SA_SESSION.SET_ROW_LABEL). |
tr>
|
SA_SESSION.SA_USER_NAME |
Returns the username associated with the current Oracle Label Securit y session |
For example, the following statement shows the current session label for the Human Resources policy:
SQL> select sa_session.label ('human_resou rces') 2 from dual; SA_SESSION.LABEL('HUMAN_RESOURCES') --------------------------------------------- L3:M,E
| See Also:<
/strong>
"Using SA_UTL Functions to Set and Return Label Information" for additional functions that return numeric label tags and BOOLEAN values |