10g Release 1 (10.1) Part Number B10774-01 |
|
|
View PDF |
10g Release 1 (10.1) Part Number B10774-01 |
|
|
View PDF |
Chapter 2 introduced the concept of labels (with thei r levels, compartments, and groups) and the basic notion of access control based on the row's data label and the user's label. The pr esent chapter examines the access controls and privileges that determine the type of access users can have to labeled rows.
This chapter contains these sections:
This section introduces the basic user labels.
Ea ch Oracle Label Security user has a set of authorizations that include:
The administrator also specifies the user's initial session label when setting up these authorizations for the user.
The session label is the particular combination of level, compartments, and group s at which a user works at any given time. The user can change the session label to any combination of components for which he is aut horized.
When a user writes data without specifying its label, a row label is assigned automatically, using the user's session lab el. However, the user can set the label for the written row, within certain restrictions on the components of the label he specifies.
The level of this label can be set to any level within the range specified by the administ rator. For example, it can be set to the level of the user's current session label down to the user's minimum level. However, the com partments and groups for this row's new label are more restricted. The new label can include only those compartments and groups conta ined in the current session label and, among those, only the ones for which the user has write access.
When the administrator sets up the user authorizations, he or she also specifies an initial default row label.
| See Also: |
The session label and the row label can fall anywhere wi thin the range of the user's level, compartment, and group authorizations. In Figure 3-2, the user's maximum level is SENSITIVE, and his minimum level is UNCLASSIFIED. However, his default session label is C:FIN,OP:WR. In this example, the administrator has set the user's session label so that the user connects to the database at the CONFIDENTIAL level.
Similarly, even though the user is authorized for compartments FIN and OP, and group WR, the ad ministrator could set the session label so that the user connects with only compartment FIN, and group WR.
Text description of the illustration olsag012.gif
< a name="1007441">There are two types of user authorizations:
The administrator explicitly sets a number of user authorizations:
The administrator explicitly sets the following level authorizations:
For exampl e, in Oracle Policy Manager, the administrator might set the following authorizations:
Text description of the illustration olslv l.gif
The administrator specifies the list of com partments that a user can place in her session label. Write access must be explicitly given for each compartment. A user cannot direc tly insert, update, or delete a row that contains a compartment that she does not have authorization to write. For example, in Oracle Policy Manager, the administrator might set the following authorizations:
Text description of the illustration olscmp.gif< /a>
In Figure 3-4, the Row designation indicates whe ther the compartment should be used as part of the default row label for newly inserted data. Note also that the LABEL_DEFAULT policy option must be in effect for this setting to be valid.
The administrator specifies the list of groups that a user can place in her session label. Write access must be explicitly given for eac h group listed. For example, in Oracle Policy Manager, the administrator might set the following authorizations:
Text description of the illustration olsgrp.gif
In Figure 3-5, t he Row designation indicates whether the group should be used as part of the default row label for newly inserted data. Note also tha t the LABEL_DEFAULT policy option must be in effect for this setting to be valid.
Oracle Label Security automatically computes a number of labels based on the value of the session label. These include:
When a table is protected by an Oracle Label Security policy, the user's label components are compa red to the row's label components to determine whether the user can access the data. In this way, Oracle Label Security evaluates whe ther the user is authorized to perform the requested operation on the data in the row. This section explains the rules and options by which user access is mediated. It contains these topics:
Although data labels are stored in a column within data records, information about user authoriza tions is stored in relational tables. When a user logs on, the tables are used to dynamically generate user labels for use during the session.
Two fundamental types of access mediation on DML operations exist, within protected tables:
The user has a maximum authorization for the data he or she can read; the user's write authorization is a subset of that. The mini mum write level controls the user's ability to disseminate data by lowering its sensitivity. The user cannot write data with a level lower than the minimum level the administrator assigned to this user.
In addition, there ar e separate lists of compartments and groups for which the user is authorized; that is, for which the user has at least read access. A n access flag indicates whether the user can also write individual compartments or groups.
When groups are organized hierarchically, a user's assigned groups i nclude all subgroups that are subordinate to the group to which she belongs. In this case, the user's read/write authorizations on a parent group flow down to all the subgroups.
Consider the parent group WESTERN_REGION, with three subgroups as illustrated in Figure 3-6. If the user has read access to WESTERN_REGION, she also has read access to the three subgroups. The administrator can give the user write access to subgroup WR_FINANCE, without gra nting her write access to the WESTERN_REGION parent group (or to the other subgroups). On the other hand, if the user has read/write access on WESTERN_REGION, then she also has read/write access on all of the subgroups subordinate to it in the tree.
Write authorization on a group does not give a user write authorization on the parent group. If a user has read-only access to WESTERN_REGION and WR_FINANCE, the administrator can grant her write access to WR_ACCOUNTS_RECEIVABLE, without af fecting her read-only access to the higher-level groups.
Text description of the illustration olsag016.gif
READ_CONTROL enforcement determines the abilit y to read data in a row. The following rules are used, in the sequence listed, to determine a user's read access to a row of data:
If the user's label passes these tests, it is said to "dominat e" the row's label.
Note that there is no notion of read or write access connected with lev els. This is because the administrator specifies a range of levels (minimum to maximum) within which a user can potentially read and write. At any time, the user can read all data equal to or less than her current session level. No privileges (other than FULL) allow the user to write below her minimum authorized level.
The label evaluation process proceed s from levels to groups to compartments, as illustrated in Figure 3-7. Note that if the data l abel is null or invalid, then the user is denied access.
Text description of the illustration olsag028.gif
As a read access request comes in, Oracle Label Security evaluates each row to determine:< /p>
If the answer is no at any stage in this evaluation process, then Oracle Label Securit y denies access to the row, and moves on to evaluate the next row of data.
Oracle Label Sec urity policies allow user sessions to read rows at their label and below, which is called reading down. Sessi ons cannot read rows at labels that they do not dominate.
For example, if you are logged in at SENSITIVE:ALPHA,BETA, you can read a row labeled SENSITIVE:ALPHA because your label dominates that of the row. However, you canno t read a row labeled SENSITIVE:ALPHA,GAMMA because your label does not dominate that of the row.
Note that the user can gain access to the rows otherwise denied, if she or he possesses special Oracle Label Security privilege s.
In the context of Oracle Label Security, WRITE_CONTROL enforcement determines the ability to inse rt, update, or delete data in a row.
WRITE_CONTROL enables you to control data access with ever finer granularity. Granularity increases when compartments are added to levels; it increases again when groups are added to comp artments. Access control becomes even more fine grained when you can manage the user's ability to write the data that he can read.
To determine whether a user can write a particular row of data, Oracle Label Security evaluat es the following rules, in the order given:
To state tests 2 and 3 another way:
Just as with read operations, the lab el evaluation process proceeds from levels to groups to compartments. Note that the user cannot write any data below her authorized m inimum level, nor above her current session level. The user can always read below her minimum level.
The following figure illustrates how the process works with INSERT, UPDATE, and DELETE operations. Note that if the data la bel is null or invalid, then the user is denied access.
Text description of the illustration olsag030.gif
As an access request comes in, Oracle Label Security evaluates each row to determine:
If the answer is no at any stage in this evaluation process, then Oracle Label Security denies access to the row, and moves on to evaluate the next row of data.
Consider a situation in which your session label is S:ALPHA,BETA but you only have write access to compartment ALPHA. In this case you can read a row with the label S:ALPHA,BETA, but you cannot update it.
< /a>In summary, write access is enforced on INSERT, UPDATE and DELETE operations upon the data in the row.
In addition, each user may have an associated minimum level below which she cannot write. She cannot u pdate or delete any rows labeled with levels below her minimum, nor can she insert a row with a row label containing a level less tha n her minimum.
| See Also: |
This sectio n introduces the Oracle Label Security database and row label privileges:
Oracle Label Security supports special priv ileges that allow authorized users to bypass certain parts of the policy. Table 3-3 summarizes the full set of privileges that can be granted to users or trusted stored program units. Each privilege is m ore fully discussed after the table.
A user's authorizations can be modified wi th any of four privileges:
A user with READ privilege can read all data protected by the policy, regardless of his authorizations or session label. The user does not even need to have label authorizations. Note, in addition, that a user with READ privilege can write to any data rows for which he or she has write access, based on any label authorizations.
|
However, access mediation is still enforced on UPDATE, IN SERT, and DELETE operations. See Chapter 8, "Implementing Policy Enforcement Options and Labeling Functions", particularly
|
This privilege is useful for system administrators who need to export data, but who should not be allowed to change d ata. It is also useful for people who must run reports and compile information, but not change data. The READ privilege enables optim al performance on SELECTs, since the system behaves as though the Oracle Label Security policy were not even present.
The FULL privilege has the same effect and benefits as the READ privilege, with one dif ference: a user with FULL privilege can also write to all the data. For a user with the FULL privilege, the R EAD and WRITE algorithms are not enforced.
Note that Oracle SYSTEM and OBJECT authorization s are still enforced. For example, a user must still have SELECT on the application table. The FULL authorization turns off the acces s mediation check at the individual row level.
The COMPACCESS priv ilege allows a user to access data based on the row label's compartments, independent of the row label's groups. If a row label has n o compartments, then access is determined by the group authorizations. However, when compartments do exist, and access to them is aut horized, then the group authorization is bypassed. This allows a privileged user whose label matches all the compartments of the data to access any data in any particular compartment, independent of what groups may own or otherwise be allowed access to the data.
Figure 3-9 shows the label evaluation process for read access with COMPACCESS privilege. Note that if the data label is null or invalid, then the user is denied access.
Text description of the illustration olsag029.gif
Figure 3-10 shows the label evaluation process for write access with COMPACCESS privilege. Note that if the data label is null or invalid, then the user is denied access.
Text descrip tion of the illustration olsag027.gif
The PROFILE_ACCESS p rivilege allows a session to change its session labels and session privileges to those of a different user. This is a very powerful p rivilege, since the user can potentially become a user with FULL privileges. This privilege cannot be granted to a trusted stored pro gram unit.
Once the la bel on a row has been set, Oracle Label Security privileges are required to modify the label. These privileges include WRITEUP, WRITE DOWN, and WRITEACROSS.
Note that the LABEL_UPDATE enforcement option must be on for these l abel modification privileges to be enforced. When a user updates a row label, the new label and old label are compared, and the requi red privileges are determined.
The WRITEUP privilege enables the user to raise the level of data within a row, without compromising the compartments or groups. The user can raise the level up to his or her maximum authorized level.
For example, an authorized user can raise the level of a data row that has a level lower than his own minimum level. If a row is UNCLASSIFIED and the user's maximum level is SENSITIVE, he can ra ise the row's level to SENSITIVE. He can raise the level above his current session level, but cannot change the compartments.
The WRITEDOWN privilege enables the user to lower the level of data within a row, without compromising the compartments or groups. The user can lower the level to any level equal to or greater than his or he r minimum authorized level.
The WRITEACROSS privilege allows the user to change the compartments and groups of data, without altering its sensitivity level. This guarantees, for example, that SENSIT IVE data remains at the SENSITIVE level, but at the same time enables the data's dissemination to be managed.
< /a>It lets the user change compartments and groups to anything that is currently defined as a valid compartment or gr oup within the policy, while maintaining the level. With the WRITEACROSS privilege, a user with read access to one group (or more) ca n write to a different group without explicitly being given access to it.
Remember that Oracle Label Security privileges are different from the standa rd Oracle9i system and object privileges.
Oracle9i
System Privileges
The right to execute a particular type of SQL statement
Object Pr ivileges
The right to access another user's object
Oracle Label Security
Policy Privileges
The ability to bypass certain parts of the label security policy
Oracle9i enforces the discretionary access control privileges that a user has been granted. By default, a user has no privileges except those granted to the PUBLIC user group. A user must explicitly be granted t he appropriate privilege to perform an operation.
For example, to read an object in Oracle9 i, you must either be the object's owner, or be granted the SELECT privilege on the object, or be granted the SELECT ANY TABLE system privilege. Similarly, to update an object, you must either be the object's owner, or be granted the UPDATE p rivilege on the object, or be granted the UPDATE ANY TABLE privilege.
| See Also:
For more information about which Or acle9i privileges are required to perform a certain operation, and how to grant and revoke these discretionar y access control privileges, see Oracle Database Administrator's Guide. |
Prior to accessing data through a view, end users must have the appropriate system and object privileges on the view. If the un derlying table (upon which the view is based) is protected by Oracle Label Security, then the end user of the view must have authoriz ation from Oracle Label Security to access specific rows of labeled data.
An administrator can choose among a set of policy enforcement options when applying an Oracle Label Security policy to individual tables. These options enable enforcement to be tailored differently for each database table. In addition to the access controls based on the labels, a SQL predicate can also be associated with ea ch table. The predicate can further define which rows in the table are accessible to the user. Policy enforcement options and predica tes are discussed in Chapter 8, "Implementing Policy Enforcement Options and Labeling Functions".
In cases where the label to be associated with a new or updated row should be automatic ally computed, an administrator can specify a labeling function when applying the policy. That function will thereafter always be invoked to provide the data labels written under that policy, because active labeling functions take precedence over any alternative means of supplying a label.
Except where noted, this guide assumes tha t all enforcement options are in effect.
This section describes aspects of using multiple policies.
Several Oracle Label Security policie s may be protecting data in a single database. Each defined policy is associated with a set of labels used only by that policy. Data labels are constrained by the set of defined labels for each policy.
Each policy may protec t a different table, but multiple policies can also apply to a single table. To access data, you must have label authorizations for a ll policies protecting that data. To access any particular row, you must be authorized by all policies protec ting the table containing your desired rows. If you require privileges, then you may need privileges for all of the policies affectin g your work.
If you work in a distributed environment, where multiple databases may be protected by the same or different Oracle Label Securi ty policies, your remote connections will also be controlled by Oracle Label Security.
|
 Copyright © 2000, 2003 Oracle Corpora tion All Rights Reserved. |
|
