Core Role Based Access Control (RBAC) mechanism for MySQL

Core Role Based Access Control (RBAC) mechanism for MySQL by Ian Molloy Radu Dondera Umang Sharan CS541 Project Report Under the Guidance of Prof. Elisa Bertino With the Department of Computer Science Purdue University, West Lafayette

Abstract RBAC or Role-Based Access Control is an approach to restrict system access to authorized users and help in implementing a secure access control for larger databases. MySQL is a popular open source relational database management system (RDBMS) which currently implements MAC and DAC access control mechanisms. We extend the access control policies in MySQL by adding the Core RBAC functionality to it. 1

Contents 1 Introduction 3 2 Role-Based Access Control 3 2.1 RBAC model and Functional Specification................. 4 2.1.1 Core RBAC.............................. 4 2.1.2 Hierarchical RBAC.......................... 5 2.1.3 Protection Policies.......................... 5 2.2 Handling Sessions............................... 6 3 Introduction to MySQL 6 3.1 System R Authorization Model....................... 6 3.2 Access Control in MySQL.......................... 7 4 Coding and Schema 8 2

1 Introduction RBAC or Role-Based Access Control is an access control mechanism that enables better access security management, restricting system access to authorized users [4] [3]. With role-based access control, access decisions are based on the roles that individual users have as part of a group or organization. The use of roles is an effective way for developing and enforcing enterprise-specific security policies. The process of defining roles should be based on a thorough analysis of how the organization operates and thus how the roles would help in granting/restricting access to authorized/unauthorized users. There have been several attempts to propose a well defined model for RBAC [1]. Consider the following example [7] to understand RBAC better: A hospital has several types of employees - Doctors, nurses, tellers, CMO, etc. Now every member of the hospital staff cannot be assigned the same privileges to the hospital resources - a doctor may have access to personal patient files while a teller may not and so on. One method is to use DAC throughout and specify all the necessary permissions on every piece of hospital equipment that every member has. But this is a wastage since on most of the resources, groups of employees (say the doctors or the nurses) tend to have the same set of permissions. Under the RBAC framework, users are granted membership into roles based on their competencies and responsibilities in the organization. The operations that a user is permitted to perform are based on the user s role. User membership into roles can be revoked easily and new memberships established as job assignments dictate. Role associations can be established when new operations are instituted and old operations can be deleted as organizational functions change and evolve. This simplifies the administration and management of privileges. Further, roles can be updated without updating the privileges for every user on an individual basis. Role-based access mechanisms have been present in commercial databases [8] like Informix Online Dynamic Server, Oracle Enterprise Server and Sybase Adaptive Server for quite some time now but MySQL uses only DAC and rudimentary MAC for access control [6]. We extend the MySQL database management system to incorporate RBAC access control policies too. 2 Role-Based Access Control The concept of Role-Based Access Control (RBAC) has been used in applications for decades but it has matured as a full-fledged access control model such as Mandatory Access Control (MAC) or Discretionary Access Control (DAC) over the past decade. RBAC policies resemble those of group access privileges in UNIX systems, privilege groupings in database management systems, etc. The modern concept of RBAC includes such notions in a single access control model based on role and role hierarchies, role activation, user/role interactions. The principal motivation behind RBAC is the 3

ability to articulate and enforce enterprise-specific security policies and the ease with which security management can be streamlined. From a functional perspective, RBAC s central notion is that of operations representing actions associated with roles and users that are made members of roles based on their job assignments and access privileges. These relationships are typically many-to-many that is to say that a user may have several roles and each role can be assigned to several users. Similarly, an action may be assigned to several roles while a role may have several actions. The operations that are associated with roles constrain members of the role to a specified set of actions. An important feature of the RBAC model is the protection policies. These include - the specification of competency to perform specific tasks; the enforcement of Least Privilege for administrators and general users and the specification, as well as the enforcement, of conflicts of interest rules, which may entail duty assignment and dynamic and static separation of duties. These policies can be enforced at the time operations are authorized for a role, at the time users are authorized as members of a role, at the time of role activation (like when a role is established as part of a user s active session) or when a user attempts to perform an operation on an object. Such decisions are implementation specific and are made based on the functionality required. 2.1 RBAC model and Functional Specification RBAC policies are described in terms of users, subjects, roles, role hierarchies, operations, and protected objects. To perform an operation on an object controlled under RBAC, a user must be active in some role. Before a user can be active in a role, that user must first have been authorized as a member of the role by a security administrator. RBAC provides administrators with the capability to place constraints on role authorization, role activation, and operation execution. These constraints have a variety of forms. Constraints include cardinality and mutual exclusivity rules which can be applied on a role-by-role basis. In addition, constraints can be placed on the authorization of an operation to a role and on operations being performed on objects (i.e. time and location constraints). Let us overview the different components of RBAC model in the following sections. 2.1.1 Core RBAC Core RBAC includes the essential features of RBAC. The basic concept of RBAC is that users are assigned to roles and permissions are assigned to roles, and users acquire permissions by being members of roles. Core RBAC includes requirements that user-role and permission-role assignment can be many-to-many. Thus the same user can be assigned to many roles and a single role can have many users. Similarly, for permissions, a single permission can be assigned to many roles and a single role can be assigned to many permissions. Core RBAC includes requirements for user-role review 4

whereby the roles assigned to a specific user can be determined as well as users assigned to a specific role. A similar requirement for permission-role review is imposed as an advanced review function. Core RBAC also includes the concept of user sessions, which allows selective activation and deactivation of roles. Finally, Core RBAC requires that users be able to simultaneously exercise permissions of multiple roles. Thus, it is evident that Core RBAC captures the aspects of traditional group-based access control used in UNIX. We have added the Core RBAC functionality to MySQL RDBMS. Core RBAC embodies the essential and most important feature set of RBAC models. Implementing Core RBAC was a natural starting point - extensions to the RBAC model like role hierarchies can be built upon our implementation easily. 2.1.2 Hierarchical RBAC Roles can have overlapping capabilities i.e., users belonging to different roles may be assigned common permissions. Furthermore, within many organizations there are a number of general permissions that are performed by a large number of users. Hierarchical RBAC adds requirements for supporting role hierarchies. A hierarchy is mathematically a partial order defining a seniority relation between roles, whereby senior roles acquire the permissions of their juniors, and junior roles acquire the user membership of their seniors. The role hierarchy may be of two types: General Hierarchical RBAC : In this case, there is support for an arbitrary partial order to serve as the role hierarchy, to include the concept of multiple inheritance of permissions and user membership among roles. Limited Hierarchical RBAC : Some systems may impose restrictions on the role hierarchy. Most commonly, hierarchies are limited to simple structures such as trees or inverted trees. 2.1.3 Protection Policies Apart from the hierarchy of roles and user-role assignments, the RBAC model also encapsulates several protection policies for static and dynamic separation of duty relations to ensure conflict resolution during privilege evaluation. For example, we may want to take care during role assignment that if a user is being assigned to multiple roles then their privileges are mutually exclusive and don t contradict each other. Similarly, we might want to restrict the number of roles a user can activate per session and so on. For a better discussion of RBAC, and the RBAC standard, we refer the reader to [5]. 5

2.2 Handling Sessions 3 Introduction to MySQL MySQL is an open-source multiuser relational database management system (RDBMS). At present, MySQL implements DAC and rudimentary MAC access control policies. 3.1 System R Authorization Model System R [2] is the seminal work on relational database management systems on which MySQL (and many others) are built. As a result, it is important to look at the authorization model of System R, and then consider how MySQL deviates from this model. System R is a multi-level discretionary access control system. When a user creates a table, they are the owner of table, and may grant privileges (access at various levels) to other users. These privileges consist of the standard operations one may perform on the table, such as select, insert, update, delete, etc. and an additional grant permission. If a user has been given the grant permission (typically known as the grant option) they may further grant any or all of his privileges on the tables other users. After a sequence of grant operations, the result is a directed graphs of granted privileges originating from the table creator, [2]. Views are handled in a similar manner, and a user may only grant permissions on a view which they hold on the underlying table (with the grant option). Revocation is slightly more complicated, and several design and implementation decisions can be made. 1. The first option is to revoke the privilege from just a single user. Such a revocation is non-cascading and non-recursive; users who obtained the privilege from the revoked principal will maintain their privilege. 2. The second option is to recursively revoke the permission from all users who (transitively) obtained the privilege from the revoked principal. This requires the system to store a grantor field for the purpose of revocation. 3. A third option is to recursively revoke the permission from all users who (transitively) obtained the privilege from the revoked principal, but to return the grant-graph to a consistent state if the revoked principal had never been granted the privilege. This requires the system to store timestamp to all grant operations. This should provide one with enough background knowledge to being to understand how MySQL handles authorization, which we will discuss next. 6

3.2 Access Control in MySQL The primary aim of the access control mechanism in MySQL or MySQL Privilege System as it is called is to authenticate a user based on his username, host and password and to associate the user with privileges on different databases and tables such as Select, Update, Insert, etc. The MySQL Privilege System ensures that a user is allowed access to inly those operations to which it has sufficient privileges. The user identity is determined by using the username as well as the hostname. MySQL access control involves two stages when you run a client program that connects to the server: The server checks whether it should allow you to connect. Thereafter, assuming that you can connect, the server checks each statement you issue to determine whether you have sufficient privileges to perform it. If your privileges are changed (either by yourself or someone else) while you are connected, those changes do not necessarily take effect immediately for the next statement that you issue. The first thing to mention when discussing MySQL authorization is its concept of the principal. A principal in MySQL is a pair consisting of the username and originating host of the request. This is an attempt to restrict permissions on less trusted hosts, and allows an administrator restrict root to localhost access only. A user authenticates using any number of methods, such as password (which may be different for each host), SSL, and X509 certificates. A principal is then granted privileges, such as select, insert, update, create on the system. When a user performs an operation, MySQL asserts that the user has sufficient privileges to perform the operation before it is executed. If their privileges do not dominate the required privileges, the access is denied. We state the granted privileges must dominate the required privileges for several reasons. First, privileges may be granted at several granularities. A user may be granted global permissions over the system (including what are referred to as super user privileges), which may be applied to any database stored within the DBMS. Second, a user may be granted privileges at the database and host level. Within each database privileges may be assigned at the table, and even column granularity. Access decisions may then be made at the column level, and a user s privileges on a column are defined by Global (Database Host) T able Column (1) The privileges are stored in table in MySQL as: It should be noted that no access control decisions query these tables directly. The access control tables are loaded into main memory when the system initializes and when a user issues the flish privileges command. No grant or revoke operations will take affect until one of these two events takes place. Privileges are granted to a user using the grant and revoke mechanisms from System R, with a few exceptions. MySQL is not a discretionary access control system. A user who creates a table 7

Scope Global Databse Host Table Column Procedures Table mysql.user mysql.db mysql.host mysql.tables priv mysql.columns priv mysql.procs priv Table 1: Storage Location for Privileges at Varying Granularities in MySQL Field Type Null Key Default Extra User char(16) NO PRI Host char(60) NO PRI Role char(64) NO PRI Table 2: rbac ua: User-Role Assignment Relationship is not the table s owner, and may have no privileges on the table they created. Consider the following listing: Listing 1: Non Discretionary Access Control in MySQL 1 REVOKE ALL ON db. FROM user ; 2 GRANT create ON db. TO user ; 3 Log in as user 4 CREATE TABLE db. table (column CHAR( 2 0 ) ) ; 5 SELECT FROM db. table ; 6 Access Denied On revocation, MySQL will choose the simplest strategy, and will not perform any cascading revocation. The grant tables do contain columns for both grantor and timespams, and cascading revocation is in the works for a future version. 4 Coding and Schema We added the following tables: Installation The mysql install scripts were modified to automatically create the rbac * tables if necessary. (See mysql create system tables) 8

Field Type Null Key Default Extra Role char(64) NO PRI Select priv enum( N, Y ) NO N Insert priv enum( N, Y ) NO N Update priv enum( N, Y ) NO N Delete priv enum( N, Y ) NO N Create priv enum( N, Y ) NO N Drop priv enum( N, Y ) NO N Reload priv enum( N, Y ) NO N Shutdown priv enum( N, Y ) NO N Process priv enum( N, Y ) NO N File priv enum( N, Y ) NO N Grant priv enum( N, Y ) NO N References priv enum( N, Y ) NO N Index priv enum( N, Y ) NO N Alter priv enum( N, Y ) NO N Show db priv enum( N, Y ) NO N Super priv enum( N, Y ) NO N Create tmp table priv enum( N, Y ) NO N Lock tables priv enum( N, Y ) NO N Execute priv enum( N, Y ) NO N Repl slave priv enum( N, Y ) NO N Repl client priv enum( N, Y ) NO N Create view priv enum( N, Y ) NO N Show view priv enum( N, Y ) NO N Create routine priv enum( N, Y ) NO N Alter routine priv enum( N, Y ) NO N Create user priv enum( N, Y ) NO N Table 3: rbac pa: Global Role Permissions 9

Field Type Null Key Default Extra Db char(64) NO PRI Role char(64) NO PRI Select priv enum( N, Y ) NO N Insert priv enum( N, Y ) NO N Update priv enum( N, Y ) NO N Delete priv enum( N, Y ) NO N Create priv enum( N, Y ) NO N Drop priv enum( N, Y ) NO N Grant priv enum( N, Y ) NO N References priv enum( N, Y ) NO N Index priv enum( N, Y ) NO N Alter priv enum( N, Y ) NO N Create tmp table priv enum( N, Y ) NO N Lock tables priv enum( N, Y ) NO N Create view priv enum( N, Y ) NO N Show view priv enum( N, Y ) NO N Create routine priv enum( N, Y ) NO N Alter routine priv enum( N, Y ) NO N Execute priv enum( N, Y ) NO N Table 4: rbac db: Database Privilege Table Field Type Null Key Default Extra Db char(64) NO PRI Role char(64) NO PRI Table name char(64) NO PRI Table priv set( Select, Insert, Update, Delete, Create, Drop, Grant, References, Index, Alter, Create View, Show view ) NO Column priv set( Select, Insert, Update, References ) NO Table 5: rbac tables priv: Table Privilege Table Field Type Null Key Default Extra Db char(64) NO PRI Role char(64) NO PRI Table name char(64) NO PRI Column name char(64) NO Column priv set( Select, Insert, Update, References ) NO Table 6: rbac columns priv: Column Privilege Table 10

Field Type Null Key Default Extra Db char(64) NO PRI Role char(64) NO PRI Routine name char(64) NO PRI Routine type enum( FUNCTION, PROCEDURE ) NO PRI Proc priv set( Execute, Alter Routine, Grant ) NO Table 7: rbac proc priv: Procedure Privilege Table Broad access control Broader access control is handled by the user, host and db databases. There are loaded into memory on system load by the acl init function and reloaded after the flush privileges cal by acl reload. We have written RBAC counterparts rbac init and rbac reload which are called upon successfully reloading the standard MySQL tables, and load the rbac ua, rbac pa and rbac db tables. Much like the standard tables, our tables are loaded into memory, and sorted by attributes (db, host, role, and user), where more explicit attributes come before less explicit wild-cards. The three main tables are searched for access rights when an operation is tested by the acl get function. For our implementation, we wrote an equivalent rbac get function, which loops through a list of activated roles, and returns the disjunction of all permissions belonging to that role, and the permissions belonging to the user. Finer Access Control Finer grained access control decisions (table, column and procedure level) are loaded by very similar methods in a function called grant init (with [re]laods as well), to which we added a family of rbac grant * functions. For the finer grained controls, there are methods check grant to check for table permissions, and store (within the tables) the structures holding the permissions at the column level. We augmented these functions load (again, by disjunction) the permissions available to all the roles, and store a list of pairs {Role,ColumnStructure} for the column level permissions. When checking permission, MySQL calls a series of check functions depending on the type of access that is requested, and the privileges still required (not inherited from a higher level). These functions include check grant, check grant column, check column grant in table ref, check grant routine, check grant db,, and have been overloaded to call RBAC equivalents. For the SQL command show grants; MySQL has defined get table grant and get column grants which are used in conjunction with acl get to determine all of the privileges granted to a user. By augmenting the appropriate functions, the privileges a user has via activated roles are also displayed. 11

References [1] Database security-concepts, approaches, and challenges. IEEE Trans. Dependable Secur. Comput., 2(1):2 19, 2005. Fellow-Elisa Bertino and Fellow-Ravi Sandhu. [2] M. M. Astrahan and M. W. Blasgen. System r: Relational approach to database management. ACM Trans. Database Syst., 1(2):97 137, 1976. [3] S. Gavrila D.Ferraiolo, R.Sandhu. Proposed nist standard for role-based access control. In ACM Transactions On Information and System Security, pages 224 274, 2001. [4] D. Ferraiolo and R. Kuhn. Role-based access controls. In 15th NIST-NCSC National Computer Security Conference, pages 554 563, 1992. [5] Ninghui Li, Ji-Wom Byun, and Elisa Bertino. A critique of the ansi standard on role based access control. 2005. [6] MySQL. The mysql access privilege system. [7] NIST. An introduction to role-based access control. 1995. [8] C. Ramaswamy and R. Sandhu. Role-based access control features in commercial database management systems. In Proc. 21st NIST-NCSC National Information Systems Security Conference, pages 503 511, 1998. 12