2.4.2 Passive Policies

Passive policies do not include implementables. They have the character of an information repository for the enforcement part of the policy management system or planning system mentioned in the section above.

Passive policies contain information about which states are desirable and acceptable, as can be seen in figure . Passive policies define an allowed state space, displayed by the square enclosed by the broken line. The diagram shows a system in the state $S_{i+1}$ from which the transitions $T_{i+1}$ and $T_{i+1, j}$ are allowed. These transitions are allowed because they will not leave the permissible state space during their execution and they bring the system into a state which is also in the allowed state space. The transition $T_{i+1, ?, x}$ leaves the permissible state space during the transition before returning to $S_j$. Whether transition $T_{i+1, ?, x}$ may be possible or not, depends on the actual (meta)policy. Therefore, it is marked with a question mark. Potential problems and questions may arise:

• If the transition fails during the execution, the system may not be compliant with the policies because it could have left the allowed state space.
• How far is an action allowed to leave the permissible state space and when must the action after the transition bring the system back to an allowed state?
• Whether an algorithm halts is not decidable, so it could run forever, and thus the action could stay outside the state space.
• It is harder to track actions which are allowed to leave the allowed space. Therefore side effects are more likely, and an altered operation would not be recognised so easily.

A possible solution for some of the questions and problems could be the realisation of state transitions similar to transactions used in databases where it is possible to roll back a change to an inconsistent state in case of a failure. This is commonly known as the two-phase commit protocol.

As mentioned in the beginning of this section, passive policies do not have actions, but they are used to allow or deny actions. This can happen in various ways: Either the information is translated into a configuration of a resource, for instance an access control list, or the policy system acts like a wrapper or proxy for the desired activity. It grants the activity if it is compliant with the specified passive policies. The activities must be well known when using this mechanism.

The first case allows for very quick operation. The latter will be much slower but has a greater flexibility, because complex constraints, which cannot be translated into static configuration files, are possible. Another advantage is the ability of recognising runtime conditions which are, in our understanding, only a particular instance of states. A mixture of these two extreme cases is also possible. In section , this is discussed in greater detail for the realisation of passive (meta)policies in an existing management system.