Abstract
Runtime enforcement is a common mechanism for ensuring that program executions adhere to constraints specified by a security policy. It is based on two simple ideas: the enforcement mechanism should leave good executions without changes (transparency) and make sure that the bad ones got amended (soundness). From the theory side, a number of papers (Hamlen et al., Ligatti et al., Talhi et al.) provide the precise characterization of good executions that can be captured by a security policy and thus enforced by mechanisms like security automata or edit automata.
Unfortunately, transparency and soundness do not distinguish what happens when an execution is actually bad (the practical case). They only tell that the outcome of enforcement mechanism should be “good” but not how far the bad execution should be changed. So we cannot formally distinguish between an enforcement mechanism that makes a small change and one that drops the whole execution.
In this paper we explore a set of policies called iterative properties that revises the notion of good executions in terms of repeated iterations. We propose an enforcement mechanism that can deal with bad executions (and not only the good ones) in a more predictable way by eliminating bad iterations.