13
Releasability Using Inverse Groups

This chapter discusses the Oracle Label Security implementation of releasability using inverse groups. It contains the following sections:

• Introduction to Inverse Groups and Releasability
• Comparing Standard Groups and Inverse Groups
• How Inverse Groups Work
• Algorithm for Read Access with Inverse Groups
• Algorithm for Write Access with Inverse Groups
• Algorithms for COMPACCESS Privilege with Inverse Groups
• Session Labels and Inverse Groups
• Changes in Behavior of Procedures with Inverse Groups
• Dominance Rules for Labels with Inverse Groups

  Note: The Oracle Policy Manager graphical user interface is not supported for policies which contain inverse groups.

Introduction to Inverse Groups and Releasability

Inverse groups indicate releasability of information: they are used to mark the dissemination of data. When you add an inverse group to a data label, the data becomes less classified. For example, a user with inverse groups UK, US cannot access data which only has inverse group UK. Adding US to that data makes it accessible to all users with the inverse groups UK, US.

When you assign releasabilities to a user, you mark the communication channel to the user. For data to flow across the communication channel, the data releasabilities must dominate the releasabilities assigned to the user. In other words, releasabilities assigned to a data record must contain all the releasabilities assigned to a user.

The advantage of releasabilities lies in their power to broadly disseminate information. Releasing data to the entire marketing organization becomes as simple as adding the Marketing releasability to the data record.

Comparing Standard Groups and Inverse Groups

Groups in Oracle Label Security identify organizations which own or access data. Like standard groups, inverse groups control the dissemination of information. However, the behavior of inverse groups differs from Oracle Label Security standard group behavior. By default, all policies created in Oracle Label Security use the standard group behavior.

The term, "releasabilities" is sometimes used to refer to the behavior provided by inverse groups. When you include inverse groups in a data label, the effect is similar to assigning label compartment authorizations to a user. When Oracle Label Security evaluates whether a user can view a row of data assigned a label with inverse groups, it checks to see whether the data, not the user, has the appropriate group authorizations: does the data have all the inverse groups assigned to the user? With standard groups, by contrast, Oracle Label Security checks to see whether a user is authorized for at least one of the groups assigned to a row of data.

Consider a policy which contains 3 standard groups: Eastern, Western, and Southern. User1's label authorizations include the groups Eastern and Western. Assuming User1 has been assigned the appropriate level and compartment authorizations in the policy, then:

• With standard Oracle Label Security groups, User1 can view all data records that have the group Eastern, or the group Western, or both Eastern and Western.
• With inverse groups, User1 can only view data records that have, at a minimum, all the groups assigned to the user: that is, both Eastern and Western. She cannot view records that have only the Eastern group, only the Western group, or that have no groups at all.

Table 13-1 shows all the rows which User1 can potentially access, given the type of group which is used in the policy.

Table 13-1 Access to Standard Groups and Inverse Groups

If row label contains groups:	User1 access with standard groups?	User1 access with inverse groups?
none	Y	N
Eastern	Y	N
Western	Y	N
Southern	N	N
Eastern, Western	Y	Y
Eastern, Southern	Y	N
Western, Southern	Y	N
Eastern, Western, Southern	Y	Y

Standard groups indicate ownership of information: thus all data pertaining to a certain department can have that department's group in the label. When you add a group to a data label, the data becomes more classified. For example, a user with no groups can access data which has no groups in its label. If you add the group US to the data label, the user can no longer access the data.

How Inverse Groups Work

This section explains how inverse groups are implemented, and how they work. It contains these topics:

• Implementing Inverse Groups with the INVERSE_GROUP Enforcement Option
• Inverse Groups and Label Components
• Computed Labels with Inverse Groups
• Inverse Groups and Hierarchical Structure
• Inverse Groups and User Privileges

Implementing Inverse Groups with the INVERSE_GROUP Enforcement Option

When creating an Oracle Label Security policy, the administrator can specify whether the policy can use inverse group functionality to implement releasability. To do this, he specifies INVERSE_GROUP as one of the default_options in the CREATE_POLICY statement.

The INVERSE_GROUP option can only be set at policy creation time. Once a policy is created, this option cannot be changed.

The INVERSE_GROUP option is thus policy-wide. It cannot be turned on or off when the policy is applied to a table or schema. If you attempt to do so, using the procedure APPLY_TABLE_POLICY or APPLY_SCHEMA_POLICY, then an error will be generated.

Whereas other policy enforcement options can be dropped from a policy, the INVERSE_GROUP policy configuration option cannot be dropped once it is set. To remove the option you must drop, and then re-create, the policy.

The administrator can give individual users authorization for one or more inverse groups.

Inverse Groups and Label Components

When an Oracle Label Security policy is created with the inverse group option, the components in the policy label (levels, compartments, and groups) are the same as with standard groups. With inverse groups, however, the user's read groups and write groups have a different meaning and role in data access.

Consider the following policy example:

There are three levels:

UNCLASSIFIED	UN
CONFIDENTIAL	CON
SECRET	SE

One compartment:

FINANCIAL

FIN

Three groups:

EASTERN	EAS
WESTERN	WES
SOUTHERN	SOU

Two user labels have been assigned: CON:FIN and SE:FIN:EAS,WES

Two data labels have been assigned: CON:FIN:EAS and SE:FIN:EAS

User access to the data differs, depending on the type of group being used:

• If the policy uses standard groups, then:

  The user with the label CON: FIN cannot read CON:FIN:EAS data.

  The user with the label SE:FIN:EAS,WES can read SE:FIN:EAS data.

• If the policy has the INVERSE GROUPS policy enforcement option, then:

  The user with the label CON: FIN can read CON:FIN:EAS data.

  The user with the label SE:FIN:EAS,WES cannot read SE:FIN:EAS data.

Computed Labels with Inverse Groups

This section explains how inverse groups affect computed label values. It contains these topics:

• Computed Session Labels with Inverse Groups
• Inverse Groups and Computed Max Read Groups and Max Write Groups

Computed Session Labels with Inverse Groups

After the administrator assigns label authorizations to a user, Oracle Label Security automatically computes a number of labels. With inverse groups these labels are as follows:

Table 13-2 Computed Session Labels with Inverse Groups

Computed Label	Definition
Max Read Label	The user's maximum level combined with his or her authorized compartments and the minimum set of inverse groups that should be in the user label (session label).
Max Write Label	The user's maximum level combined with the compartments for which the user has been granted write access. Contains the maximum authorized inverse groups that can be set in any label. The user has write authorizations on all these inverse groups.
Min Write Label	The user's minimum level.
Default Read Label	The default level, combined with compartments and inverse groups which have been designated as default for the user.
Default Write Label	A subset of the default read label, containing the compartments and inverse groups for which the user has been granted write access. However the inverse groups component has no significance as it is the Max Write Groups which is always used for write access.
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 for the data label for inserted data. The Inverse groups should be a superset of inverse groups in the default label and a subset of Max Write Groups.

Inverse Groups and Computed Max Read Groups and Max Write Groups

From the computed values in Table 13-2, two sets of groups are identified for label evaluation of read and write access:

Max Read Groups	This is the set of groups contained in the Max Read Label. It identifies the minimum set of inverse groups that can be set in any user label.
Max Write Groups	This is the set of groups contained in the Max Write Label. It identifies the maximum authorized inverse groups that can be set in any user label. This set of groups is checked at the time of write access, and also when setting session labels. Note that Max Write Groups is a superset of Max Read Groups.

As shown in Table 13-3, for standard groups you can have READ ONLY and READ/WRITE authorizations; for inverse groups you can have WRITE ONLY and READ/WRITE authorizations.

Table 13-3 Read and Write Authorizations for Standard Groups and Inverse Groups

	READ ONLY	READ/WRITE	WRITE ONLY
Standard Groups	The group is present only in Max Read Label, not in Max Write Label.	The group is present in both Max Read Label and Max Write Label.	Not supported
Inverse Groups	Not supported	The group is present in both Max Read Label and Max Write Label.	The group is present only in Max Write Label, not in Max Read Label.

Although Max Read Groups identifies the set of groups contained in the Max Read Label, this value represents the minimum set of inverse groups that can be set. For example:

Max Read Groups: S:C1:G1,G2

Max Write Groups: S:C1:G1,G2,G3,G4,G5

Here, the user can read data which contains at least the 2 groups listed in Max Read Groups.

Note that in standard groups, there can never be a situation in which there are more groups in the Max Write Label than in the Max Read Label.

Inverse Groups and Hierarchical Structure

Standard groups in Oracle Label Security are hierarchical, such that a group can be associated with a parent group. For example, the EASTERN region can be the parent of two subordinate groups: EAS_SALES, and EAS_HR.

In a policy with standard groups, if the user label has the parent group, then it can access all data of the subordinate groups.

With inverse groups, parent-child relationships are not supported.

Inverse Groups and User Privileges

With inverse groups implemented, the meaning of user privileges remains the same.

When the user has no special privileges, then the read algorithm and the write algorithm are different for groups and inverse groups. The differences are described below, in "Algorithm for Read Access with Inverse Groups" and "Algorithm for Write Access with Inverse Groups".

The effect of inverse groups on the COMPACCESS privilege is described below, in "Algorithms for COMPACCESS Privilege with Inverse Groups".

Inverse groups have no impact upon the following user privileges:

• PROFILE_ACCESS
• WRITEUP
• WRITEDOWN
• WRITEACROSS

Algorithm for Read Access with Inverse Groups

This section describes the algorithm for read access with inverse groups.

To read data in a table with the INVERSE GROUP option in effect, the label evaluation process proceeds from levels to groups to compartments, as illustrated in Figure 13-1. (Note that the current session label is the label being evaluated.)

1. The user's level must be greater than or equal to the level of data
2. The user's label must include all the compartments assigned to the data
3. The groups in the data label must be a superset of the groups in the user label.

If the user's label passes these tests, then he can access the data. If not, he is denied access. Note that if the data label is null or invalid, then the user is denied access.

Figure 13-1 Label Evaluation Process for Read Access with Inverse Groups

Text description of the illustration releasa.gif

Algorithm for Write Access with Inverse Groups

This section describes the algorithm for write access with inverse groups.

To write data in a table with the INVERSE GROUP option, the label evaluation process proceeds from levels to groups to compartments, as illustrated in Figure 13-2. (Note that the current session label is the label being evaluated.)

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. One of the following conditions must be met:

   The groups in the data label must be a superset of the groups in the user label.

   or

   The user has READ access privilege on the policy.

3. The user's Max Write Groups must be a superset of the data label groups.
4. The user label must have write access on all of the compartments in the data label.

Note that if the data label is null or invalid, then the user is denied access.

Figure 13-2 Label Evaluation Process for Write Access with Inverse Groups

Text description of the illustration releas2.gif

Algorithms for COMPACCESS Privilege with Inverse Groups

This section describes the algorithms for read and write access with inverse groups, for users who have COMPACCESS privilege.

The COMPACCESS privilege allows a user to access data based on the row's compartments, independent of the row's groups.

• When compartments exist, and access to them is authorized, then the group authorization is bypassed.
• If a row has no compartments, then access is determined by the inverse group authorizations.

Figure 13-3 and Figure 13-4 show the label evaluation process for read access and write access for a user with COMPACCESS privilege. If the data label is null or invalid, then the user is denied access.

(Note that the current session label is the label being evaluated.)

Figure 13-3 Label Evaluation for Read Access with COMPACCESS Privilege and Inverse Groups

Text description of the illustration releas3.gif

Figure 13-4 Label Evaluation for Write Access with COMPACCESS Privilege and Inverse Groups

Text description of the illustration releas4.gif

Session Labels and Inverse Groups

This section describes how inverse groups affect session labels and and row labels.

• Inverse Groups with SA_USER_ADMIN.SET_DEFAULT_LABEL and SA_USER_ADMIN.SET_ROW_LABEL
• Inverse Groups with SA_SESSION.SET_ROW_LABEL and SA_SESSION.SET_LABEL
• Examples of Session Labels and Inverse Groups

Inverse Groups with SA_USER_ADMIN.SET_DEFAULT_LABEL and SA_USER_ADMIN.SET_ROW_LABEL

The use of inverse groups affects the behavior of Oracle Label Security procedures which determine the session label. The SA_USER_ADMIN.SET_DEFAULT_LABEL and SA_USER_ADMIN.SET_ROW_LABEL procedures set the user's initial session label and row label, respectively, to the one specified.

Rules for Changing Default Labels with Standard Groups

A user's default session label can be changed using SA_USER_ADMIN.SET_DEFAULT_LABEL. In the case of standard groups, the default session label can be set to include any groups in the authorized list, as long as the current default row label will still be dominated by the new write label. That is, the row label will have the same or fewer standard groups than the new write label.

The same rule applies for SA_USER_ADMIN.SET_ROW_LABEL.

Rules for Changing Default Labels with Inverse Groups

In the case of inverse groups, the default session label can be set to include any groups in the authorized list, as long as the current default row label will still be dominated by the new write label. That is, the row label will have the same or more inverse groups than the new write label.

The same rule applies for SA_USER_ADMIN.SET_ROW_LABEL.

Inverse Groups with SA_SESSION.SET_ROW_LABEL and SA_SESSION.SET_LABEL

The use of inverse groups affects the behavior of the SA_SESSION.SET_LABEL and SA_SESSION.SET_ROW_LABEL procedures, which can be used to set the user's current session label and row label, respectively.

Rules for Changing Session Label with Standard Groups

With standard groups, the SA_SESSION.SET_LABEL procedure can be used to set the session label to include any groups in the user's authorized group list. (Subgroups of authorized groups are implicitly included in the authorized list.) Note that if you change the session label, this may affect the value of the session's row label.

Use the SET_ROW_LABEL procedure to set the 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.

Rules for Changing Session Label and Row Label with Inverse Groups

With inverse groups, the addition of groups to the session label decreases a user's ability to access sensitive data with fewer groups. The removal of groups enables him to access more sensitive information. The user should thus be allowed to add groups to the session label, as long as Max Read Groups is a subset of the groups in the session label, and Max Write Groups is a superset of groups in the session label. The same restriction applies when a user removes groups from his session label.

Note that there are no subgroups of authorized groups when using inverse groups. This is because parent groups are not allowed in policies using inverse groups.

Use the SET_ROW_LABEL procedure to set the row label value for the current database session. The compartments in the label must be a subset of compartments in the session label to which the user has write access.

The user is allowed to add inverse groups to the row label, as long as the session label inverse groups are a subset of the row label inverse groups, and Max Write Groups is a superset of inverse groups in the row label.

For example:

• If the user has the inverse groups UK, US as his Max Read Groups, and UK,US,CAN as his Max Write Groups. He can set his session label to C:ALPHA:UK,US,CAN but not to C:ALPHA:UK.
• If the user has the inverse group UK as his Max Read Groups, and UK,CAN as his Max Write Groups.assigned to him. He can set his session label to C:ALPHA:UK,CAN but cannot change it to either C:ALPHA or C:ALPHA:UK,US,CAN.

  See Also: "Changing the Session Label with SA_SESSION.SET_LABEL" "Changing the Row Label with SA_SESSION.SET_ROW_LABEL"

Examples of Session Labels and Inverse Groups

This section presents examples to illustrate the use of inverse groups.

Inverse Groups Example 1

Consider a User1, of a policy that implements inverse groups. The user has the following labels:

Max Read Label	SE:ALPHA,BETA:G1,G2
Max Write Label	SE:ALPHA:G1,G2,G3
Default Read Label	SE:ALPHA,BETA:G1,G2
Default Write Label	SE:ALPHA:G1,G2
Default Row Label	SE:ALPHA:G1,G2

These values are derived from the foregoing labels:

Max Read Groups	G1,G2
Max Write Groups	G1,G2,G3

The following conclusions can be drawn:

• User1 can update data with label SE:ALPHA:G1,G2 as well as data with label SE:ALPHA:G1,G2,G3. User1 cannot, however, update label SE:ALPHA:G1.

  If standard groups were being used, rather than inverse groups, then User1 could update data with label SE:ALPHA:G1.

• Data which User1 inserts has the label SE:ALPHA:G1,G2. (This is the same as with standard groups.)
• If User1 leaves the default label as is, and sets his row label to SE:ALPHA:G1,G2,G3, then he will insert SE:ALPHA:G1,G2,G3 in new rows of data he writes. (In standard groups, he can never set more groups in the row label than in the default label.)

Inverse Groups Example 2

Consider a User1, of a policy that implements inverse groups. The user has the following labels:

Max Read Label	C:ALPHA:
Max Write Label	C:ALPHA:G1,G2,G3
Default Read Label	C:ALPHA:
Default Write Label	C:ALPHA:
Default Row Label	C:ALPHA:

These values are derived from the foregoing labels:

Max Read Groups	(an empty set)
Max Write Groups	G1,G2,G3

The following conclusions can be drawn:

• User1 can update any data with level C, compartment ALPHA, and any combination of groups G1, G2, G3, or no groups. He inserts the label C:ALPHA: in new data he writes.
• User2, who has Max Read Groups of G1,G2 or G1,G3, and so on, will not be able to view the data written by User1. This is because User1's Default Row Label contains no groups.
• User1 can choose to set inverse groups in his row label, as long as the inverse groups in the session label dominates the row label (that is, his session label contains the same or fewer groups than contained in the row label).

  This is true because the row label must have at least the groups in the session label, and can at most have the Maximum Write Groups. If the session label is G1, then you can set the groups in the row label from G1 to the Max Write Groups (G1,G2,G3).

• If User1 sets his session label and row label to C:ALPHA:G1:G2:G3, then his data becomes accessible to anyone who has any combination of G1,G2,G3 in his Max Read Groups.

  See Also: "Computed Session Labels"

Changes in Behavior of Procedures with Inverse Groups

When the INVERSE_GROUP option is specified at the time the policy is created, a change occurs in the algorithms which determine the read and write access of the user to labeled data. This section describes how inverse groups affect the behavior of the following procedures:

• SYSDBA.CREATE_POLICY with Inverse Groups
• SYSDBA.ALTER_POLICY with Inverse Groups
• SA_USER_ADMIN.ADD_GROUPS with Inverse Groups
• SA_USER_ADMIN.ALTER_GROUPS with Inverse Groups
• SA_USER_ADMIN.SET_GROUPS with Inverse Groups
• SA_USER_ADMIN.SET_USER_LABELS with Inverse Groups
• SA_USER_ADMIN.SET_DEFAULT_LABEL with Inverse Groups
• SA_USER_ADMIN.SET_ROW_LABEL with Inverse Groups
• SA_COMPONENTS.CREATE_GROUP with Inverse Groups
• SA_COMPONENTS.ALTER_GROUP_PARENT with Inverse Groups
• SA_SESSION.SET_LABEL with Inverse Groups
• SA_SESSION.SET_ROW_LABEL with Inverse Groups
• LEAST_UBOUND with Inverse Groups
• GREATEST_LBOUND with Inverse Groups

SYSDBA.CREATE_POLICY with Inverse Groups

The CREATE_POLICY procedure under the SYSDBA package creates the policy, defines an optional policy-specific column name, and specifies a set of default policy options. With inverse group support the user has one more policy enforcement option, INVERSE_GROUP. For example:

 PROCEDURE CREATE_POLICY (
 HR IN VARCHAR2,
 SA_LABEL IN VARCHAR2 DEFAULT NULL,

INVERSE_GROUP IN VARCHAR2 DEFAULT NULL);

SYSDBA.ALTER_POLICY with Inverse Groups

The ALTER_POLICY procedure under the SYSDBA package enables you to change a policy's default enforcement options, except for the INVERSE_GROUP option. Once a policy is configured for inverse groups, it cannot be changed.

SA_USER_ADMIN.ADD_GROUPS with Inverse Groups

The ADD_GROUPS procedure adds groups to a user, indicating whether the groups are authorized for write as well as read.

The access_mode is one of two variables which specify the type of access authorized.

READ_WRITE	Indicates that write is authorized. (That is, the group is contained in both Max Read Groups and Max Write Groups.)
WRITE_ONLY	Indicates that the group is contained in Max Write Groups and not in Max Read Groups
in_def	Specifies whether these groups should be in the default groups (Y/N)
in_row	Specifies whether these groups should be in the row label (Y/N)

Note that if in_def is Y in a row, then in_row must also be set to Y, but not vice versa.

If the access mode is set to READ_WRITE, the group is added to Max Read Groups, and Max Write Groups. If the group should be added only to the Max Write Groups, then the access mode should be set to SA_UTL.WRITE_ONLY. If not specified, access_mode is set to SA_UTL.READ_WRITE. If in_def is not specfied, then it will be set to Y or N depending on whether the access mode is READ_WRITE or WRITE_ONLY, respectively. The same is the case with the in_row field.

SA_USER_ADMIN.ALTER_GROUPS with Inverse Groups

The ALTER_GROUPS procedure changes the write access, the default label indicator, and/or the row label indicator for each of the groups in the list.

The behavior of inverse groups is the same as described in the case of ADD_GROUPS.

SA_USER_ADMIN.SET_GROUPS with Inverse Groups

The SET_GROUPS procedure assigns groups to a user and identifies default values for the user's session label and row label. Inverse groups are handled differently from standard groups, as follows:

read_groups	A comma-separated list of groups which would be Max Read Groups.
write_groups	A comma-separated list of groups which would be Max Write Groups. It must be a superset of read_groups.
def_groups	Specifies the default groups. It should at least have the read_groups and write_groups should be a superset of def_groups.
row_groups	Specifies the row groups. It should at least have the def_groups and should be a subset of max write groups.

SA_USER_ADMIN.SET_USER_LABELS with Inverse Groups

The SET_USER_LABELS procedure sets the user's levels, compartments, and groups using a set of labels, instead of the individual components. Inverse groups are handled differently from standard groups, as follows:

max_read_label	Specifies the label string to be used to initialize the user's maximum authorized read label. Composed of the user's maximum level, compartments authorized for read access, and if inverse groups, minimum set of groups that can be set in any label.(Max Read Groups)
max_write_label	Specifies the label string to be used to initialize the user's maximum authorized write label. Composed of the user's maximum level, compartments authorized for write access, and if inverse groups, the maximum authorized groups that can be set in any label (Max Write Groups). All the inverse groups in this have write authorization also. It should be a superset of groups in max_read_label. If the max_write_label is not specified, it is set to max_read_label.
def_label	Specifies the label string to be used to initialize the user's session label, including level, compartments, and groups (a subset of max_read_label). If the default_label is not specified, it is set to the max_read_label. For inverse groups, component it should at least have the groups in max_read_label, and groups in max_write_label should be a superset of the groups in the def_label.
row_label	Specifies the label string to be used to initialize the program's row label. Includes levels, compartments, and groups: subsets of max_write_label and def_label. If row_label is not specified, it is set to the def_label, with only the compartments and groups authorized for write access. The inverse groups component is set to same as that in def_label if the row_label is not specified. The inverse groups in row label should at least be those in default label and should be a subset of Max Write Groups.

SA_USER_ADMIN.SET_DEFAULT_LABEL with Inverse Groups

The SET_DEFAULT_LABEL procedure sets the user's initial session label to the one specified.

All the rules mentioned for setting inverse groups component of session label mentioned in "Session Labels and Inverse Groups" are applicable here.

SA_USER_ADMIN.SET_ROW_LABEL with Inverse Groups

Use the SET_ROW_LABEL procedure to set the user's initial row label to the one specified.

When specifying the row_label, the inverse groups component must contain at least all the inverse groups in def_label and should be a subset of Max Write Groups.

SA_COMPONENTS.CREATE_GROUP with Inverse Groups

Use the CREATE_GROUP procedure to create a group and specify its short name and long name, and optionally a parent group.

With inverse groups the parent_name field should always be NULL. If the user specifies a value for this field, then an error message is displayed, indicating that the group hierarchy is disabled.

SA_COMPONENTS.ALTER_GROUP_PARENT with Inverse Groups

This function is disabled for policies with the inverse group option. An error message is displayed if the user invokes this function.

SA_SESSION.SET_LABEL with Inverse Groups

Use the SET_LABEL procedure to set the label of the current database session.

For the current user, this procedure follows the same rules for setting the session label as does the sa_user_admin.set_user_label function.

SA_SESSION.SET_ROW_LABEL with Inverse Groups

Use the SET_ROW_LABEL procedure to set the default row label value for the current database session.

For the current user, this procedure follows the same rules for setting the row label as does the sa_user_admin.set_row_label function.

LEAST_UBOUND with Inverse Groups

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.

With standard groups, 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.

With inverse groups, the least upper bound is the highest level, the union of the compartments in the labels, and the intersection of the inverse groups in the labels.

For example, with inverse groups the least upper bound of HIGHLY_SENSITIVE:ALPHA:G1,G2 and SENSITIVE:BETA:G1 is HIGHLY_SENSITIVE:ALPHA,BETA:G1

GREATEST_LBOUND with Inverse Groups

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.

With standard groups, the greatest lower bound is the lowest level, and the intersection of the compartments in the labels and the groups in the labels.

With inverse groups, the greatest lower bound is the lowest level, and the intersection of the compartments in the labels and the union of inverse groups in the labels.

For example, with inverse groups the greatest lower bound of HIGHLY_SENSITIVE:ALPHA:G1,G3 and SENSITIVE::G1 is SENSITIVE:G1,G3

Dominance Rules for Labels with Inverse Groups

Dominance rules for Oracle Label Security with standard groups can be summarized as follows:

A user label dominates a data label if:

Dominance rules for Oracle Label Security with inverse groups can be summarized as follows:

A user label dominates a data label if: