Strong and Provably Secure Database Access Control

Existing SQL access control mechanisms are extremely limited. Attackers can leak information and escalate their privileges using advanced database features such as views, triggers, and integrity constraints. This is not merely a problem of vendors lagging behind the state-of-the-art. The theoretical foundations for database security lack adequate security definitions and a realistic attacker model, both of which are needed to evaluate the security of modern databases. We address these issues and present a provably secure access control mechanism that prevents attacks that defeat popular SQL database systems.

💡 Research Summary

The paper “Strong and Provably Secure Database Access Control” tackles a critical gap in modern relational database management systems (RDBMS): the inability of existing SQL access‑control mechanisms to protect against attacks that exploit advanced features such as views, triggers, and integrity constraints. The authors begin by demonstrating five concrete attacks—three targeting integrity (trigger privilege escalation, view‑based unauthorized delegation, and REVOKE propagation errors) and two targeting confidentiality (information leakage via primary‑key/foreign‑key violations and via trigger‑driven side‑effects). These attacks were manually executed against six major commercial and open‑source systems (IBM DB2, Oracle, PostgreSQL, MySQL, SQL Server, Firebird), revealing that none of the platforms prevent all attacks; most fail to stop at least one integrity or confidentiality breach.

The root cause identified is twofold: (1) the SQL standard and vendor implementations define access‑control rules only for a limited “SELECT‑only” attacker, ignoring data‑modifying commands (INSERT, DELETE, GRANT, REVOKE) and the dynamic behavior of triggers, views, and constraints; (2) there is no formal security definition that captures the intended protection goals, making it impossible to reason about or verify the correctness of any implementation.

To remedy this, the authors develop a comprehensive formal framework consisting of three main contributions:

1. Operational Semantics – A rigorous, executable semantics for a core SQL subset that includes SELECT (modeled via relational calculus), INSERT, DELETE, GRANT/REVOKE (with GRANT OPTION and CASCADE), CREATE VIEW, CREATE TRIGGER (AFTER INSERT/DELETE only), and user management. The semantics captures both static policy aspects and dynamic state changes, including the privilege context under which triggers execute.

2. Extended Attacker Model – The attacker is allowed to issue any of the above commands, to read the definitions of existing triggers, views, and constraints, and to observe error messages and query results. This model subsumes the traditional SELECT‑only model and reflects realistic capabilities of insider or compromised users.

3. Security Properties – Two mathematically precise properties are defined:

   • Database Integrity: No unauthorized user can cause any change to the database state or to the access‑control policy, directly or indirectly (e.g., via trigger execution).
   • Data Confidentiality: No unauthorized user can infer any protected data, even by exploiting the semantics of triggers, views, or constraint violations.

Using the operational semantics, the authors prove that each of the five attacks violates at least one of these properties. They then design a provably secure access‑control mechanism that intercepts every command, simulates its effect using the semantics, and checks whether the resulting state would breach the integrity or confidentiality definitions. If a violation is detected, the command is rejected. This policy engine is implemented in Maude, providing an executable reference model and enabling automated verification of the security proofs.

Experimental evaluation shows that the proposed mechanism blocks all five attacks on the same DBMS platforms used for the initial case studies. Moreover, the overhead of the policy checks is shown to be modest, confirming practical feasibility. The paper also includes a thorough discussion of related work, highlighting that prior proposals either ignore advanced SQL features or lack formal attacker models and security definitions.

In summary, the authors deliver a full stack solution: a formal attacker model, precise security definitions, an executable semantics for a realistic SQL subset, and a policy enforcement architecture that can be formally verified. This work bridges the gap between theoretical database security and real‑world DBMS implementations, offering a blueprint for future standards and for the design of robust, provably secure database access‑control systems.