A formal framework for reflective database access control policies

Abstract

Reflective Database Access Control (RDBAC) is a model in which a database privilege is expressed as a database query itself, rather than as a static privilege contained in an access control list. RDBAC aids the management of database access controls by improving the expressiveness of policies. However, such policies introduce new interactions between data managed by different users, and can lead to unexpected results if not carefully written and analyzed. We propose the use of Transaction Datalog as a formal framework for expressing reflective access control policies. We demonstrate how it provides a basis for analyzing certain types of policies and enables secure implementations that can guarantee that configurations built on these policies cannot be subverted.

An Access Control Language for a General Provenance Model

“…Rosenthal et al [29] suggest that policies should be evaluated under the privilege of the query issuers rather than the policy authors. In contrast, Olson et al [30] suggest that policies should be evaluated under the privilege of the policy authors rather than the query issuers. In either approach, it is possible that predicates in policies cannot be successfully evaluated due to the lack of privileges.…”

Fine-Grained Access Control with Object-Sensitive Roles

“…The database community has also addressed the enforcement of instance-level access control policies (e.g., [12,26,20,22]). In particular, [12] extends RBAC with parameterized role templates, where the parameters of a template refer to database columns or constants and serve a similar function as our role parameters.…”

Implementing Reflective Access Control in SQL

“…Reflective Database Access Control (RDBAC) is an access control model that addresses this problem [16]. We define a policy as reflective when it depends on data contained in other parts of the database.…”

“…This type of security policy is not available in transaction managers for general-purpose databases, and must be enforced at the application level. We chose to use TD due to its formal semantics that enable provable security properties for certain policies [16]. Similar compilation strategies applied to other more common policy languages, such as XACML [15], could be implemented.…”

“…However, this autonomy comes at a price. We have shown that careless definitions of reflective policies can be vulnerable to a Trojan Horse attack if untrusted users are also allowed to define policies [16]. This problem can easily be mitigated using TD-based policies by restricting a policy definer from performing any operations beyond what that user can perform manually: we simply make the user's ID an explicit parameter to all view predicates, and for all predicates in the body of a policy, that parameter is bound to the ID of the policy definer, thereby executing the policy under the policy definer's privileges.…”