When a user accesses a row, one of three outcomes will occur:
1. The user has privilegesthat bypass row label security (denoted by the number 1 in Figure 12.7).
2. The user must pass the write mediation algorithmto modify data in the row (denoted by the number 2 in Figure 12.7).
3. The user must pass the read mediation algorithmto read data (denoted by the number 3 in Figure 12.7).
M I D - L E V E L A R C H I T E C T U R E 288
User Joe
FULL Privilege?
UPDATE LABEL?
READ Privilege?
DELETE CONTROL?
READ CONTROL?
INSERT CONTROL?
WRITE CONTROL?
UPDATE CONTROL?
NO CONTROL?
ACCESS TYPE
ACCESS TYPE
NO
NO
READ
NO WRITE
NO
INSERT STATEMENT
DELETE STATEMENT
UPDATE STATEMENT
NO PROFILE
ACCESS privilege?
User Jane
Access Row Level Data
STOP
YES
YES
YES
NO
ENFORCE READ ACCESS ALGORITHM
ENFORCE WRITE ACCESS ALGORITHM
1
2
2 1
2
NO
YES YES
1 2
YES
NO
3
YES
1
3
1
1
4
2
NO YES
1
YES
See next figure.
Figure 12.7 Label modification in row-label access. (See Figure 12.8 for legend.)
Each of the three components of a label carries its own semantics for read and write access:
Level.The level of a data label places it within the level hierarchy. Oracle assigns a range of levels, from a MAXIMUM to a MINIMUM, to each user. When the user connects to the database, a DEFAULT level is assigned to the user between these extremes. Each row in tables using row level security is assigned a row level. Users may not access rows with levels greater than their MAXIMUM level, and may not write to rows with labels lower than their MINIMUM level, the latter to prevent users from lowering the level of a row and allowing unauthorized access. This is known as write-down control or the *-property.
Compartments.The compartment component of a label is a set of category names.
Users are assigned read compartments defining the data categories that they have read access to, and are assigned write compartments defining data categories that they can modify.
Groups.Users can be given read or write access to groups and requests are resolved as follows. On a read request, the user’s read access groups must match or be a subset of the read groups of the label. On a write request, the user’s write access groups must match or be a subset of the write groups of the label.
Configuring CONTROLS enables security policy. If a READ CONTROL is applied to a user, only authorized rows are accessible on SELECT, UPDATE, or DELETE queries.
Similarly, if WRITE control is applied to a user, all attempts to INSERT, DELETE, or UPDATE data will only be applied to authorized roles. Additional controls provide more policy definition options.
Because OLS presents an additional performance cost on every access, the designers provided a mechanism to bypass the row-level label checks by using User Privilege Authorizations. For example, a user with the READ privilege can access all data that would otherwise be protected by label security, regardless of the value of the row label. Access would be enforced, however, on non-SELECT statements. Similarly, the FULL privilege bypasses all row label security. In this case, no mediation checks are performed.
Users might be allowed to modify the labels associated with the data that they are allowed to access. All modifications must be done in a consistent manner, observing level constraints.
Figure 12.7 describes the control flow of row-level security enforcement by using a flowchart. The shaded decision boxes represent user privileges. If user Joe has the pro- file access privilege, he can change his identity during the access decision to that of another user. This example shows delegation at work within label security. If the user hasread,write, or full privileges, he or she can directly access the data. This situation is shown in Figure 12.7, using the entry point 1 to access data and stop the process flow.
If the user does not have certain privileges, then access controls are only enforced if policy requires them to be enforced. The non-shaded decision boxes represent checks to see whether the policy requires that an access decision be invoked. A user can freely
execute INSERT, DELETE, or UPDATE statements on the row if the controls for guard- ing these actions are disabled.
However, if the security policy requires the read and write access mediation checks by enabling the appropriate controls, we must extract the row label and the user’s label and compare the two labels to make an access decision. This scenario is captured in Figure 12.7 by the two floating flowcharts that originate with the start elements (labeled 3 and 2, respectively).
Finally, a user can seek to change the security level of a label. This procedure is dis- played in Figure 12.8. The label is a distinguished column in the row because it is used for access decisions. Modifications to the label can only be made if the user has privi- leges that allow him or her to modify the label or if the label update control is not enforced.
We have simplified the OLS security scheme here to make the case that multi-level data- base security is not only a viable security mechanism in commercial applications but
M I D - L E V E L A R C H I T E C T U R E 290
WRITE DOWN Privilege?
WRITEUP Privilege?
LEVEL CHANGE DIRECTION
DOWN UP
BLOCK ACCESS
MODIFY LABEL YES
NO NO 4
WRITE ACROSS Privilege?
LABEL UPDATE CONTROL?
Level Component
updated?
YES
Compartment or Group
NO
YES Privilege test
Action Row Level Data
Control or decision
n
n LEGEND
Continuation point end
Continuation point start
NO
YES
Figure 12.8 Label modification in row-label access.
TEAMFLY
Team-Fly®
also to emphasize the core differences with controlling user access at the row level and controlling user access at a much coarser structural level.
One good architectural feature is the provision of privileges that enable row-level label security features to be bypassed. OLS checks can add an unacceptable performance penalty for certain database operations. If these operations are performed only by a subset of the users whose database access is controlled by using other mechanisms, it makes sense to lift this security check and allow faster access. This function does not necessarily weaken security, but it can actually help with another architecture goal:
performance.
Row-level security is implemented within OLS as a special instance of a complex row- level security scheme with application context definition along with a pre-built collec- tion of policy functions, through enhancements to the database engine. Both the context and the policy functions can be further modified to customize behavior. Users can define label functions that compute the label values on INSERT and UPDATE state- ments or add additional SQL predicates to policy functions. The management of secu- rity policy is through a GUI-based tool called the Oracle Policy Manager. Labels can be viewed as an active version of the sentinel pattern, where the database engine checks the label before granting access. The label itself is not modified unless explicitly tar- geted by the user through a label-modifying update statement.
OLS has additional features that make for interesting security discussions, but in the interests of generality and brevity, we will refer the interested reader to the resources on Oracle Technical Network on the Oracle FGAC and OLS products.