A logical framework for reasoning on data access control policies

Abstract

In this paper we propose a logic formalism that naturally supports the encoding of complex security specifications. This formalism relies on a hierarchically structured domain made of subjects, objects and privileges.Authorizations are expressed by logic rules. The formalism supports both negation by failure (possibly unstratified) and true negation. The latter is used to express negative authorizations. It turns out that conflicts may result from a set of authorization rules. Dealing with such conflicts requires the knowledge of the domain structure, such as grantor priorities and object/subject hierarchies, which is used in the deductive process to determine which authorization prevails, if any, on the others. Often, however, conflicts are unsolvable, as they express intrinsic ambiguities.We have devised two semantics as an extension of the well-founded and the stable model semantics of logic programming. We have also defined a number of access policies, each based on two orthogonal choices: one is related to the way how we cope with multiplicity of authorization sets in case of stable model semantics; the other is concerned with the open/closed assumption. A comparative analysis of the proposed authorization policies, based on their degree of permissivity, shows that they form a complete lattice.

Evolution of the Ethane Architecture

“…Conflicts between policy modules entered by different administrators can be detected by automated methods [44,7,36] that can be built into policy management tools. At the same time, because FSL policies are used by real systems [14,26,52], any conflicts that are not resolved by administrative tools must be resolved automatically at enforcement time [53,36,12,10,24,27,48,11]. Unlike prior languages, FSL conflict resolution is complicated by the fact that policies can reference external sources [48,13,41], which can change independent of the policy.…”

“…Because disagreements naturally arise among administrators, FSL was designed so that those disagreements would manifest as conflicts in policies [53,36,12,10,24,27,48,11,7]. Conflicts between policy modules entered by different administrators can be detected by automated methods [44,7,36] that can be built into policy management tools.…”

“…Sometimes the conflict-resolution scheme for a language is built-in [48,24,11], but sometimes it is defined by the user [10,53,27]. Sometimes, conflicts are only detected but not resolved [7], and other times conflicts are handled by a combination of detection and user-defined resolution [36].…”

Defining and Measuring Policy Coverage in Testing Access Control Policies

“…A variety of policy languages and models have been proposed. Some of them are generic [1,14,25,26,37] while others are designed for specific applications [7,11,36,38] or data models [8,9,19,29].…”

Rule-Based Policy Representation and Reasoning for the Semantic Web

“…Some authors regard multiple models as an opportunity to write nondeterministic specifications where each model is an acceptable policy and the system makes an automatic choice between the available alternatives [34]. For instance, the models of a policy may correspond to all possible ways of assigning permissions that preserve a Chinese Wall policy [35].…”