Read and Write Conditions

At the conceptual level, all conditions can be categorized as:

• Conditions that require reading some system variable and comparing it with the information specified in the policy. For example, evaluation of the time condition requires obtaining current time and checking if it fits into the time interval specified in the policy. We call this category of conditions read conditions. A read condition is represented as 16#16, where 13#13 is the name of a system variable, 2#2 is a constant and 17#17 is the operation (e.g., 18#18 , 19#19 , 20#20 , 21#21) to be performed on the value of the system variable 13#13 and the constant 2#2. In implementation, this value maybe either obtained from the request or read using the 12#12 operation during the condition evaluation.

• Conditions that require writing some information (e.g., audit) or initiating some action (e.g., notification). We call this category of conditions write conditions. A write condition is represented as 22#22, where 13#13 is the name of the system variable and 23#23 is the new value to be assigned.

An obvious relationship between the read and write conditions is if one condition requires reading of a system variable, which is written by the other condition. In our framework, the condition evaluation process is totally ordered. The order has to be assessed before condition evaluation starts. Determining the correct order of the conditions in the policy statement is an important issue. Human judgment is a necessary component in this process. We feel that the function of defining the condition order can be best served by having the policy officer chose a meaningful condition order. In particular, whether the write conditions must be evaluated before the read conditions. The goal of the system is to faithfully implement the given organizational security policy.