Skip Headers

Oracle Label Security Administrator's Guide
Release 2 (9.2)

Part Number A96578-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

3
Understanding Access Controls and Privileges

Chapter 2 introduced the concept of labels (with their levels, compartments, and groups) and the basic notion of access control based on the row's data label and the user's label. The present chapter examines the access controls and privileges which determine the type of access users can have to the rows affected.

This chapter contains these sections:

Introduction to Access Mediation

To access data protected by an Oracle Label Security policy, a user must have authorizations based on the labels defined for the policy. Figure 3-1 illustrates the relationships between users, data, and labels.

Figure 3-1 Relationships Between Users, Data, and Labels

Text description of olsag011.gif follows
Text description of the illustration olsag011.gif



Note:

Oracle Label Security provides a number of enforcement options which affect the way in which access controls are applied to tables and schemas. This chapter assumes that all policy enforcement options are in effect.

For more information, see "Choosing Policy Options".




Understanding Session Label and Row Label

This section introduces the basic user labels.

The Session Label

Each Oracle Label Security user has a set of authorizations which include:

When the administrator sets up these authorizations for the user, he or she also specifies the user's initial session label.

The session label is the particular combination of level, compartments, and groups at which a user works at any given time. The user can change the session label to any combination of his or her authorized components.

The Row Label

The row label is the particular label assigned by default to data which a user enters during a session. It can be set to any level, from the one specified in the user's current session label, down to the user's minimum level. It can include only compartments and groups contained in the current session label, and for which the user has write access. The user can change the row label to any label for which he or she is authorized.

When the administrator sets up the user authorizations, he or she also specifies an initial default row label.

Session Label Example

The session label and the row label can fall anywhere within 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 administrator could set the session label so that the user connects with only compartment FIN, and group WR.

Figure 3-2 User Session Label

Text description of olsag012.gif follows
Text description of the illustration olsag012.gif


Understanding User Authorizations

There are two types of user authorizations:

Authorizations Set by the Administrator

The administrator explicitly sets a number of user authorizations:

Authorized Levels

The administrator explicitly sets the following level authorizations:

Table 3-1 Authorized Levels Set by the Administrator
Authorization Meaning

User Max Level

The maximum ranking of sensitivity which a user can access during read and write operations

User Min Level

The minimum ranking of sensitivity which a user can access during write operations. The User Max Level must be equal to or greater than the User Min Level.

User Default Level

The level which is assumed by default when connecting to Oracle9i

User Default Row Level

The level which is used by default when inserting data into Oracle9i



For example, in Oracle Policy Manager, the administrator might set the following authorizations:

Figure 3-3 Setting Up Authorized Levels

Text description of olslvl.gif follows
Text description of the illustration olslvl.gif


Authorized Compartments

The administrator specifies the list of compartments which a user can place in her session label. Write access must be explicitly given for each compartment. A user cannot directly insert, update, or delete a row that contains a compartment which she does not have authorization to write. For example, in Oracle Policy Manager, the administrator might set the following authorizations:

Figure 3-4 Setting Up Authorized Compartments

Text description of olscmp.gif follows
Text description of the illustration olscmp.gif


In Figure 3-4, the Row designation indicates whether 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.

Authorized Groups

The administrator specifies the list of groups which a user can place in her session label. Write access must be explicitly given for each group listed. For example, in Oracle Policy Manager, the administrator might set the following authorizations:

Figure 3-5 Setting Up Authorized Groups

Text description of olsgrp.gif follows
Text description of the illustration olsgrp.gif


In Figure 3-5, the Row designation indicates whether the group 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.

See Also:

Chapter 6, "Administering User Labels and Privileges" for instructions on setting the authorizations

"LABEL_DEFAULT: Using the Session's Default Row Label"



Computed Session Labels

Oracle Label Security automatically computes a number of labels based on the value of the session label. These include:

Table 3-2 Computed Session Labels
Computed Label Definition

Maximum Read Label

The user's maximum level combined with his or her authorized compartments and groups.

Maximum Write Label

The user's maximum level combined with the compartments and groups for which the user has been granted write access.

Minimum Write Label

The user's minimum level.

Default Read Label

The single default level combined with compartments and groups which have been designated as default for the user.

Default Write Label

A subset of the default read label, containing the compartments and groups to which the user has been granted write access. The level component is equal to the level default in the read label. This label is automatically derived from the read label based on the user's write authorizations.

Default Row Label

The combination of components between the user's minimum write label and the maximum write label, which has been designated as the default value for the data label for inserted data.

See Also:

"Computed Labels with Inverse Groups"

How Labels Are Evaluated for Access Mediation

When a table is protected by an Oracle Label Security policy, the user's label components are compared to the row's label components to determine whether the user can access the data. In this way, Oracle Label Security evaluates whether 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:

Introduction to Read/Write Access

Although data labels are stored in a column within data records, information about user authorizations is stored in relational tables. When a user logs on, the tables are used to dynamically generate user labels for use during the session.

Difference Between Read and Write Operations

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 minimum write level controls the user's ability to disseminate data by lowering its sensitivity. The user cannot write data to any level lower than his or her minimum level.

In addition, there is a list of compartments for which the user is authorized; that is, for which the user has at least read access. An access flag indicates whether the user can also write individual compartments.

There is also a list of groups for which the user is authorized; that is, for which the user has at least read access. An access flag indicates whether the user can also write individual groups.

Propagation of Read/Write Authorizations on Groups

When groups are organized hierarchically, a user's assigned groups include 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 granting 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 affecting her read-only access to the higher-level groups.

Figure 3-6 Subgroup Inheritance of Read/Write Access

Text description of olsag016.gif follows
Text description of the illustration olsag016.gif


See Also:

"Introduction to User Label and Privilege Management"

"How Inverse Groups Work"



The Oracle Label Security Algorithm for Read Access

READ_CONTROL enforcement determines the ability 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:

  1. The user's level must be greater than or equal to the level of the data.
  2. The user's label must include at least one of the groups which belong to the data (or the parent group of one such subgroup).
  3. The user's label must include all the compartments which belong to the data.

If the user's label passes these tests, it is said to "dominate" the row's label.

Note that there is no notion of read or write access connected with levels. 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 proceeds from levels to groups to compartments, as illustrated in Figure 3-7. Note that if the data label is null or invalid, then the user is denied access.

Figure 3-7 Label Evaluation Process for Read Access

Text description of olsag028.gif follows
Text description of the illustration olsag028.gif


As a read access request comes in, Oracle Label Security evaluates each row to determine:

  1. Is the user's level equal to, or greater than, the level of the data?
  2. If so, does the user have access to at least one of the groups present in the data label?
  3. If so, does the user have access to all the compartments present in the data label? (That is, are the data's compartments a subset of the user's compartments?)

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.

Oracle Label Security policies allow user sessions to read rows at their label and below, which is called reading down. Sessions 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 cannot 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 privileges.

See Also:

"Privileges Defined by Oracle Label Security Policies"

"Analyzing the Relationships Between Labels"

"Algorithm for Read Access with Inverse Groups"

The Oracle Label Security Algorithm for Write Access

In the context of Oracle Label Security, WRITE_CONTROL enforcement determines the ability to insert, 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 compartments. Access control becomes even more fine grained when you can manage the user's ability to write the data which he can read.

To determine whether a user can write a particular row of data, Oracle Label Security evaluates the following rules, in the order given:

  1. The level in the data label must be greater than or equal to the user's minimum level and less than or equal to the user's session level.
  2. When groups are present, the user's label must include at least one of the groups with write access which appear in the data label (or the parent of one such subgroup). In addition, the user's label must include all the compartments in the data label.
  3. When no groups are present, the user's label must have write access on all of the compartments in the data label.

To state tests 2 and 3 another way:

Just as with read operations, the label evaluation process proceeds from levels to groups to compartments. Note that the user cannot write any data below her authorized minimum 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 label is null or invalid, then the user is denied access.

Figure 3-8 Label Evaluation Process for Write Access

Text description of olsag030.gif follows
Text description of the illustration olsag030.gif


As an access request comes in, Oracle Label Security evaluates each row to determine:

  1. Is the data's level equal to, or less than, the level of the user?
  2. Is the data's level equal to, or greater than, the user's minimum level?
  3. If the data's level falls within the foregoing bounds, does the user have write access to at least one of the groups present in the data label?
  4. If so, does the user have access to all the compartments with at least read access which are present in the data label?
  5. If there are no groups, but there are compartments, then does the user have write access to all of the compartments?

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.

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 update or delete any rows labeled with levels below her minimum, nor can she insert a row with a row label containing a level less than her minimum.

See Also:

"Algorithm for Write Access with Inverse Groups"

Using Oracle Label Security Privileges

This section introduces the Oracle Label Security database and row label privileges:

Privileges Defined by Oracle Label Security Policies

Oracle Label Security supports special privileges which allow authorized users to bypass certain parts of the policy. Table 3-3 lists the full set of privileges which can be granted to users or trusted stored program units.

Table 3-3 Oracle Label Security Privileges
Security Privilege Explanation

READ

Allows read access to all data protected by the policy

FULL

Allows full read and write access to all data protected by the policy

COMPACCESS

Allows a session access to data authorized by the row's compartments, independent of the row's groups

PROFILE_ACCESS

Allows a session to change its labels and privileges to those of a different user

WRITEUP

Allows users to set or raise only the level, within a row label, up to the maximum level authorized for the user. (With LABEL_UPDATE enforcement.)

WRITEDOWN

Allows users to set or lower the level, within a row label, to any level equal to or greater than the minimum level authorized for the user. (With LABEL_UPDATE enforcement.)

WRITEACROSS

Allows a user to set or change groups and compartments of a row label, but does not allow changes to the level. (With LABEL_UPDATE enforcement.)

Special Access Privileges

A user's authorizations can be modified with any of four privileges:

READ

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.

This privilege is useful for system administrators who need to export data, but who should not be allowed to change data. It is also useful for people who must run reports and compile information, but not change data. The READ privilege enables optimal performance on SELECTs, since the system behaves as though the Oracle Label Security policy were not even present.

FULL

The FULL privilege has the same effect and benefits as the READ privilege, with one difference: a user with FULL privilege can also write to all the data. For a user with the FULL privilege, the READ and WRITE algorithms are not enforced.

COMPACCESS

The COMPACCESS privilege allows a user to access data based on the row's compartments, independent of the row's groups. If a row has no compartments, then access is determined by the group authorizations. However, when compartments do exist, and access to them is authorized, then the group authorization is bypassed. This allows privileged users to access all of the data for a 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.

Figure 3-9 Label Evaluation Process for Read Access with COMPACCESS Privilege

Text description of olsag029.gif follows
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.

Figure 3-10 Label Evaluation Process for Write Access with COMPACCESS Privilege

Text description of olsag027.gif follows
Text description of the illustration olsag027.gif


PROFILE_ACCESS

The PROFILE_ACCESS privilege allows a session to change its session labels and session privileges to those of a different user. This is a very powerful privilege, since the user can potentially become a user with FULL privileges. This privilege cannot be granted to a trusted stored program unit.

Special Row Label Privileges

Once the label on a row has been set, Oracle Label Security privileges are required to modify the label. These privileges include WRITEUP, WRITEDOWN, and WRITEACROSS.

Note that the LABEL_UPDATE enforcement option must be on for these label modification privileges to be enforced. When a user updates a row label, the new label and old label are compared, and the required privileges are determined.

WRITEUP

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 which has a level lower than his own minimum level. If a row is UNCLASSIFIED and the user's maximum level is SENSITIVE, he can raise the row's level to SENSITIVE. He can raise the level above his current session level, but cannot change the compartments.

WRITEDOWN

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 her minimum authorized level.

WRITEACROSS

The WRITEACROSS privilege allows the user to change the compartments and groups of data, without altering its sensitivity level. This guarantees, for example, that SENSITIVE data remains at the SENSITIVE level, but at the same time enables the data's dissemination to be managed.

It lets the user change compartments and groups to anything that is currently defined as a valid compartment or group within the policy, while maintaining the level. With the WRITEACROSS privilege, a user with read access to one group (or more) can write to a different group without explicitly being given access to it.

System Privileges, Object Privileges, and Policy Privileges

Remember that Oracle Label Security privileges are different from the standard Oracle9i system and object privileges.

Table 3-4 Types of Privilege
Source Privileges Definition

Oracle9i

System Privileges

The right to execute a particular type of SQL statement

Object Privileges

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 which 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 the appropriate privilege to perform an operation.

For example, to read an object in Oracle9i, 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 privilege on the object, or be granted the UPDATE ANY TABLE privilege.

See Also:

For more information about which Oracle9i privileges are required to perform a certain operation, and how to grant and revoke these discretionary access control privileges, see Oracle9i Database Administrator's Guide



Access Mediation and Views

Prior to accessing data through a view, end users must have the appropriate system and object privileges on the view. If the underlying table (upon which the view is based) is protected by Oracle Label Security, then the end user of the view must have authorization from Oracle Label Security to access specific rows of labeled data.

Access Mediation and Program Unit Execution

In Oracle9i, if User1 executes a procedure which belongs to User2, the procedure runs with User2's system and object privileges. However, any procedure executed by User1 runs with User1's own Oracle Label Security labels and privileges. This is true even when User1 executes stored program units owned by other users.

Figure 3-11 illustrates this process:

Figure 3-11 Stored Program Unit Execution

Text description of olsag017.gif follows
Text description of the illustration olsag017.gif


Stored program units can become "trusted" when an administrator assigns them Oracle Label Security privileges. A stored program unit can be run with its own autonomous Oracle Label Security privileges, rather than those of the user who invokes it. For example, if you possess no Oracle Label Security privileges in your own right, but execute a stored program unit which has the WRITEDOWN privilege, you can update labels. In this case, the privileges used are those of the stored program unit, and not your own.

Trusted program units can encapsulate privileged operations in a controlled manner. By using procedures, packages, and/or functions that have been assigned privileges, you may be able to access data that your own labels and privileges would not authorize. For example, to perform aggregate functions over all of the data in a table, not just the data visible to you, you might make use of a trusted program unit set up by an administrator. Program units can thus perform operations on behalf of users, without the need to grant privileges directly to users.

See Also:

Chapter 9, "Administering and Using Trusted Stored Program Units"



Access Mediation and Policy Enforcement Options

An administrator can choose among a set of policy enforcement options when applying an Oracle Label Security policy to individual tables. These provide mechanisms to tailor the enforcement differently for each database table. In addition to the access controls based on the labels, a SQL predicate can also be associated with each table, to further define the rows in the table accessible to the user. In cases where the label associated with a new or updated row should be automatically computed, an administrator can specify a labeling function that will always be invoked to provide the data label.

Except where noted, this guide assumes that all enforcement options are in effect.

See Also:

Chapter 7, "Implementing Policy Options and Labeling Functions"



Multiple Oracle Label Security Policies

This section describes aspects of using multiple policies.

Multiple Oracle Label Security Policies in a Single Database

There may be several Oracle Label Security policies protecting data in a single database. Each defined policy is associated with a set of labels that are used only by that policy. Data labels are constrained by the set of defined labels for each policy.

The tables protected may be disjoint, or in some cases a single table may be protected by more than one Oracle Label Security policy. You must have label authorizations for all policies protecting the data you need to access. To access any particular row, you must be authorized by all policies protecting the table. If you require privileges, then you may need privileges for all of the policies affecting your work.

Multiple Oracle Label Security Policies in a Distributed Environment

If you work in a distributed environment, where multiple databases may be protected by the same or different Oracle Label Security policies, your remote connections will also be controlled by Oracle Label Security.

See Also:

Chapter 11, "Using Oracle Label Security with a Distributed Database"




Go to previous page Go to next page
Oracle
Copyright © 2000, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback