We first distinguish between two types of dependencies on low-integrity data that violates Biba: (1) read integrity violations and (2) read-write integrity violations. The difference is that, in the second case, writes by our TCB may be revised by a lower integrity process. While this is not strictly an issue in Clark-Wilson (i.e., these data may be UDIs), we are not comfortable with the possibility that a TCB subject write UDI data. Thus, we always classify read-write integrity violations as likely CDIs.
If we believe data are likely to be CDIs, then we have the following options to resolve the conflicts: (1) trusting the low-integrity subject (i.e., add it to the TCB); (2) exclude the low-integrity subject; (3) exclude the conflicted object type; (4) policy override; and (5) change the policy. It is possible to extend the proposed TCB, but since we want to keep the TCB minimal and the addition of more subject types will probably introduce more constraints, this is a low priority option.
We can exclude either the conflicting object type or the low-integrity
subject type from the system to resolve an integrity conflict. Since
we are analyzing the SELinux example policy to create a security
target, it is perfectly reasonable to remove subject that cause
significant integrity issues that we do not trust. For example,
insmod_t installs modules into the kernel, but for a high
integrity system we will compile the modules into the kernel. Thus,
integrity conflicts caused by this service can be ignored. The
exclusion of object types may be less plausible given that the object
may be necessary for correct processing, but there are some cases
where this makes sense. For example, we can eliminate integrity
conflicts if we preclude objects of the type removable_device_t
which may be acceptable for a secure system.
Lastly, we can change the policy by adding overriding statements (e.g., denying the violating read or write) or by modifying the SELinux example policy itself. We have found that handling integrity violations as exceptions or defining special handling for conflicting assignments with common semantics are both effective in reducing the need to express even more complex and fine-grained policies [12]. Modifying the SELinux example policy is a last resort: it is complex enough.
If we believe data are likely to be UDIs, we may assume that the TP is protected or protects itself by sanitizing its UDI inputs. Certification may depend on receiving only specific inputs, in practice, so providing external sanitization may also be an option. We may also identify the need for other security processing, such as auditing and intrusion detection, upon use of UDIs. We see this simply as another alternative to denials.