Diesel: Applying Privilege Separation to DatabaseAccessAdrienne Porter FeltMatthew FinifterJoel WeinbergerDavid WagnerElectrical Engineering and Computer SciencesUniversity of California at BerkeleyTechnical Report No. UCB/EECS-2010-149http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-149.htmlDecember 8, 2010Copyright © 2010, by the author(s).All rights reserved. Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission.Diesel: Applying Privilege Separation to Database AccessA. Porter Felt Matthew Finifter Joel Weinberger David WagnerDecember 8, 2010AbstractDatabase-backed applications typically grant complete database access to every part of the applica-tion. In this scenario, a flaw in one module can expose data that the module never uses for legitimatepurposes. Drawing parallels to traditional privilege separation, we argue that database data should besubject to limitations such that each section of code receives access to only the data it needs. We callthis data separation. Data separation defends against SQL-based errors including buggy queries and SQLinjection attacks and facilitates code review, since a module’s policy makes the extent of its databaseaccess explicit to programmers and code reviewers. We design and construct a system called Diesel,which implements data separation by intercepting database queries and applying modules’ restrictionsto the queries. We evaluate Diesel on three widely-used applications: Drupal, JForum, and WordPress.1 IntroductionThe principle of least privilege states that each principal should receive the privileges needed to performits intended task and nothing more. Following this principle limits the scope of a bug or malicious attackand is commonly regarded as a good security and software engineering practice [26]. A privilege-separatedapplication applies the principle of least privilege internally, decomposing the program into modules so thateach module receives only the privileges it needs [24]. This provides error containment: a bug can leak onlythe privileges of the module that contains it, even if the application as a whole is highly privileged.We propose applying privilege separation to data access within database-backed applications, which werefer to as data separation. With data separation, each module receives access to only the data needed forits intended task. A data-separated module receives a restricted connection instead of a regular databaseconnection, and a policy limits the set of operations allowed over the module’s restricted connection. Asoftware developer can limit each module to the data required by that module’s functionality. An application-side data separation framework provides a policy enforcement mechanism. We value data separation for thesame reasons we value traditional privilege separation:• Additional line of defense for bugs. If a bug is present in a module, the damage that can resultis limited to the set of operations the module can perform. This means that a bug in database-facingcode (e.g., a SQL injection vulnerability) can read or corrupt only the parts of the database that areaccessible to that module.• Simpler code review. Data separation aids code review. The reviewer can determine the potentialimpact of a bug in any given module, which makes it possible to devote extra attention to moduleswhose failures could endanger the integrity or confidentiality of critical data.Traditional database user access control and data separation are complementary. Database access controllimits human users’ privileges, whereas data separation limits the data accessible to code modules. Dataseparation mitigates attacks in which a user is tricked into attacking her own data. For example, a cross-siterequest forgery attack could prompt a user’s browser to submit a form with a SQL injection attack thatdeletes the user’s data. A second-order SQL injection attack [22] or a combination cross-site scripting andSQL injection attack could similarly damage a user’s data without her knowledge. User-based database access1control would allow these attacks, since the user issuing the query has the required privileges. However, dataseparation limits the extent of these attacks to the data used by the vulnerable module. Similarly, dataseparation can enhance reliability. For example, a calendar display module cannot accidentally edit billingtables. Modules will be limited from performing unnecessary operations even if user-based access controlsallow the user to perform those actions through another module.In practice, database-provided access control is often not used at all. Most web applications connect toa database with the same database user for all human users. This common practice is due to connectionpooling, large numbers of human users, and a lack of database support for row-based database permissions.Data is particularly endangered in this scenario. If the application’s logic is wrong or vulnerable, the entiredatabase is at risk of exposure. Data separation can limit the extent of such an error in application logic: abuggy calendar module might leak all users’ calendars, but data separation can prevent it from also leakingthe billing and administrative tables.We envision our system being particularly useful in the following scenarios:• Capability-secure programs. Capability systems provide a platform in which it is possible to limitand verify which parts of a program have access to which resources [18]. Data separation is a way forcapability-secure programs to interact securely with a database.• Web applications. Web applications typically use connection pooling [28], wherein the server estab-lishes a fixed number of connections and reuses them between instances of the web application. Allof the connections are associated with the same user, which represents the web application and notthe client-side human user. With our data separation framework, connections from the connectionpool can be dynamically restricted based on the identity of the currently running module and/or thelogged-in user.• Secure extensibility. Third-party program extensions are usually