School Database Management System

Adam Oest, Hashem Assayari, Patrick Muhire

ABSTRACT
The security of databases relies on various factors including the security of the database implementation, the machine the database is running on, the network within which the database resides, client interfaces, etc. While it may seem trivial to secure a database, it can be a hard task given all the dierent kinds of attacks that can be carried out these days, the simplest being denial of service. A secure database has three main attributes: integrity, condentiality, and availability of the database and the data stored within it. To demonstrate how databases can be secured and how to apply the mentioned three concepts in that respect, a project is implemented using MySQL 5.6 as the DBMS on a Windows Server 2008 VM. The database reects a mini school database to store grades of students in dierent classes and provides 3 basic roles; administrators, instructors and students. To ensure condentiality, user roles will determine the permissions given to that user and their respective view. Account groups are setup to ensure that everyone can see the information relevant to their group and role. To ensure integrity, Foreign keys are used to keep related information in join tables together. To ensure availability, data will be provided to authenticated users with enough permissions whenever requested through a user interface over the network. This paper will explain how databases can be secured and explore the three security attributes in more detail and address some challenges of achieving this goal.

1.

OVERVIEW

Providing a secure database system is a great challenge in light of todays technology. So many attacks are carried against corporate databases where valuable information such as credit card and identity information are stored. We are implementing a simple school database system to demonstrate how databases can be secured to protect against unauthorized data modications, unauthorized access to data, and unauthorized deletion of data. Our focus throughout the project will be to ensure that

each of the three types of users in our system (students, faculty, and administrators) will be able to do what they want and need to do without compromising any data or accessing restricted data. We will have ve main database tables: one for grades, one for assignments, one for classes, one for persons, and one that maps persons to the classes they are involved with. The person table will contain records for not only students but also faculty members. Students should be able to view their own grades, classes, and assignments only, but not make any changes to them. Instructors will be able to add, edit, or remove grades of their own students, and add, edit, or remove assignments in their own classes. They will also be able to view all existing classes and student enrollment. Administrators will be able to add, edit, or delete records in any table, but they will not be able to alter the schema of any table or drop any table. All users will be able to make changes to their personal information within the person table. As a security measure, helper tables showing whether or not a record has been deleted will be in use, so that even if a teacher deletes an assignment or a grade, it will still be stored in the database. Similarly, logs will be used to keep track of changes to grades. The views we create for each type of user will ensure that the user will only see the data that he or she is authorized to see, even if more data actually exists in the system. Once all these components are implemented, we expect any malicious user who is given a student or instructor account to be unable to obtain or alter any data that we did not explicitly state was possible for their account type and user id. Our client application will be written in Java and it will allow users to access the database system. The rst thing that the user will see is a login prompt. After successfully logging in, a user will be shown an interactive listing of all the actions that he or she is allowed to do. While the client application will prevent the user from executing malicious queries, the DBMS should prevent such queries from successfully running even if they do end up being submitted. The rest of the paper will be structured as follows; We explain the architecture and design consideration in section 3. Then in section 4, We go into how the system is implemented. In section 5, we discuss the security features we integrated in our system. In section 6, we briey explain our Client application. In section 7, we explain the data contained in the database. In section 8, we discuss matters of the attack phase where each team attacks two other teams and report their ndings. In section 9, we talk about the lessons we learned from this project. In section 10, we discuss the current status of our project and future work. A

Copyright 2012 ACM X-XXXXX-XX-X/XX/XX ...$10.00.

conclusion follows in section 11.

4.

IMPLEMENTATION

2.

PROJECT MOTIVATION

This project is part of a coursework for the Secure Database System class at RIT, in which, teams of 3 students will develop and secure database systems and try to attack each other by exploiting vulnerabilities. The goal of this project is to learn how to develop a secure database system, how to maintain it and what actions to take in case of an attack.

In this section, we will discuss our implementation of the system in more detail. specically, well be talking about the hardware we used, the DBMS, and client application that we will be developing.

4.1

Hardware

3.

ARCHITECTURE AND DESIGN CONSIDERATION

We used a Windows Server 2008 R2 64-bit as the operating system. This copy of Windows has more security mechanisms in place than a regular copy of Windows. We chose Windows instead of linux for better compatibility and because the MySQL workbench is only supported on Windows platforms. At some point during the development, we switched to a 32-bit version of the Server 2008 due to compatibility issues with workbench. Things didnt go very well with the DBMS installation, so we rolled back to using the 64-bit version of Windows.

4.2

DBMS

We are implementing our secure database on a Windows MySQL 5.5 server installation. We have primarily been using the MySQL workbench desktop software to do data modeling and schema generation, as this software provides a graphical user interface which makes database components easier to visualize. We originally decided to use MyISAM as the storage engine as it is easier to backup and restore MyISAM les on the lesystem. However, we later discovered that MyISAM does not properly enforce foreign key constraints, so we decided to go ahead and convert to the InnoDB storage engine. We will now be performing SQL dumps more frequently in order to ensure that we dont lose any data. Figure 1: Design Diagram (png).

4.3
We designed a simple school database system that consists of 5 basic tables; Person, Class, Grade, Assignment and ClassStudent. We also have a sixth table that only the root user can see which is the log table. The persons table contains information about all the people in the school including student, teachers and registrars. Information about people consists of their ID, name, physical address and email. The class table contains all the dierent classes that are oered. Information about classes include the class ID, Instructors ID, the name/capacity of the class and the room number where the class is held. the grade table contains the following information; the assignment ID, the student ID and the score the student got in the assignment. The assignment table contains the assignment ID, the classID, the name of the assignment and the date when the assignment was created. the classtudent table contains the registration information of who signed up for what. We have 3 basic views; registrar, teacher and student. Each view will limit users ability to only see their own records. Thus we have ne-grained access control in place. We decided to implement a role-based mandatory access control (RBMAC) where we limit users ability to access the database based on their role and that each user can only get their access privileges from the root. This schema allows for convenient implementation and testing of security policies, which we describe in the the remainder of this document. The schema has been prepopulated with sample data, most of which is going to be restricted to an individual user or group of users.

Client Application

We have created a client application for users to access the database. During the rst steps of our project1 all our development has been done through the MySQL workbench. But, now after creating the client application we can get access to the database using the client application. More on the client application can be found in section 5.

5.

SECURITY

Although we have been sticking to the original plan for the most part, we have added more security features beyond those in the abstract, including auditing (logging) and a new user role called registrar. We will be outlining all of our security features in this section. Now our database keeps all the logs of users who try to get connected to it. And every update is stored in the logs table. The only user allowed to have access to the logs table is the database administrator.

5.1

Access Policies and Granularity

From a high level, we implement a Role-Based Mandatory Access Control (RBMAC) security policy which places strict limitations on what tasks each user role can perform. RoleBased Access Control (RBAC) is a type of policy which denes a number of user roles, each of which has a given permission set. Mandatory Access Control (MAC) dictates that no user role should be able to change the permissions of another role, and also, the permissions given to each role will be the bare minimum needed for the tasks which each role is expected to perform.

Table 2: The Views Name Description myinfo Returns person.name, person.personId, person.email, person.address. For your user studentinfo Returns class.name, assignment.name, gradebook.score, person.name. For your classes, your assignments, your grades, and your teachers instructorclasses Returns class.name, class.classId, person.name, person.personId, person.address, person.email. For your classes and enrolled students instructorgradebook Returns class.name, class.id, assignment.name, assignment.assignmentId, person.name, person.personId, grades.score. For your class assignments and enrolled students

project was activity logging/auditing. We have created different users who can be connected on our database via the created client application, and they have distinct permissions on what they can access and perform on it. Just before any insert, update, or delete operation is performed, a log message is created so that the database administrator can see what users have been doing. This logging mechanism is implemented using MySQL triggers. In addition, auditing is performed whenever a stored procedure is called, thus painting a picture of any type of user activity in the database. Within each log entry we store: 1. The table corresponding to the action performed 2. The action performed (insert, delete, or update) 3. The data before the action 4. The data after the action 5. The user performing the action 6. The timestamp of the action

Our main roles, in decreasing order of access, are: 1. Registrar 2. Instructor 3. Student The nal role belongs to the database administrator, who is the only person that has the power to assign roles to other users. Students can only access information relevant to themselves. They can update their personal information but they cant modify anything else (such as grades or classes). Instructors can alter their own class assignments and grades, and they can view other classes in the system. They cannot modify any classes, nor any grades and assignments that belong to other courses. Registrars generally have access to the entire database, but they cannot alter the schema. The database administrator will only grant INSERT and UPDATE permissions to these three roles. The DELETE permission is never granted (one must mark a row as deleted instead, using an UPDATE statement). Everything has been revoked from instructors and student. We use views and stored procedures to further restrict access to the database, through Fine-Grain Access Control (schema-based permissions unfortunately do not provide enough granularity). Table 1 describes the dierent procedures that we have implemented: We have created four dierent views within the database and have revoked the SELECT permission entirely from all student and instructor users. These views allow these users to access only the data which they should be viewing. Table 2 summarizes these view and they do. Similarly, we have created a number of procedures for instructors to allow them to update their grades and assignments. A procedure has also been created so that any user can update his or her personal information without having to run a traditional SQL statement. Thus, the main outcome of this access policy is that no low-privileged user (any instructor or teacher) can run any SQL statement on the database outside of views or procedures.

Thanks to items 3, 4, and 6, data will be traced and restored in the event of a system breach. In order to maximize security, only the database administrator has access to the activity log. All other users cant even see that the table exists. This logging will allow us to reconstruct the state of the database at any point in time. Modications made by stored procedures are also logged in this system, although they are implemented without the use of triggers. Only database administrators have access to the log table, meaning that malicious users will not be aware of which actions have been logged. Furthermore, they have no way of knowing that auditing is even enabled on our database.

5.3

Hardware Proong

Currently, we have multiple virtual machines running on RLES. The DBMS implementation is running on its own virtual machine, and all of our development and queries are being run from other virtual machines connected on the local network. This way, we are limiting access to the actual server and data by not allowing users into the server machine, and we are providing a more secure environment for developers to make changes to the database. All virtual machines are protected by a Windows account, and users are not given access to administrator accounts. All default users have been disabled on both the machines and the DBMS.

5.4

Data Integrity

5.2

Logging and Auditing

A key feature that we added during phase one of the

In order to ensure data integrity within our database, we apply foreign key constraints to all tables that reference other tables. This means that there is a foreign key constraint on the instructor of each class, the class of each assignment, the assignment and student entry in each grade, and the class and student entries in the class-student mapping table. Even though this is our primary means of ensuring data integrity, our RBMAC security policy, logging/auditing, and other steps used to harden the system also contribute to the overall integrity of the data. In order to prevent data from being deleted, no users have the DELETE permission. Instead, we have added a column

Name updateMyInfo insertAssignment UpdateAssignment insertGrade

Table 1: Parameters name (varchar), email (varchar) classId (int), name (varchar), date (int) assignmentId (int), name (varchar), date (int), delete (enum 0, 1) assignmentId (int), personId (int), score (int) assignmentId (int), personId (int), score (int), delete (enum 0, 1)

updateGrade

Procedures Description Updates a persons information with the supplied parameters Creates a new assignment entry given that the assignment is owned by the teacher executing the query Updates a given assignment with the specied parameters given the assignment is owned by the teacher executing the query Creates a new grade item for a given assignment provided the teacher executing the query own both the assignment and the student Updates a grade item for a given assignment provided the teacher executing the query own both the assignment and the student

called deleted to each table which denotes whether or not the corresponding record should be displayed. Students and instructors cannot view rows that have deleted set to a value of 1. Furthermore, our stored procedures (used by low-privileged users) help ensure data integrity by checking that the user is allowed to perform certain transactions.

6.

DATABASE CLIENT

We provide a simple command-line client that can access our database. Given the username and password as arguments, this client will connect to the database and allow the user to execute any MySQL query statement. An informative error message will be shown if the statement is malformed or if the user does not have permission to execute it. If the procedure is successfully executed, the number of aected rows, or the result set will be shown, depending on the query type.

will be repeated for instructor-level accounts and the registrar account. While students and instructors will only have access to certain data (as described in section 2), once our attackers get access to the registrar account, they should be able to view all data in the database. However, under no circumstance should they be able to alter our schema, delete rows, or drop tables. Furthermore, we should be able to trace every action made by our attackers through our audit log. If we end up being unable to do this, or if our attackers get access to more data than they were authorized to see, then one or more vulnerabilities will be existing in our system, and we will need to address those vulnerabilities.

8.2

Attacking Other Teams Database Systems

In this section, we will be discussing how we attacked other teams including the general audit plan that we followed to perform our attacks.

8.2.1

Audit Plan

7.

USERS AND DATA

Our database is pre-populated with two student users, two instructor users, and one registrar user. Each student is enrolled in two classes, and a number of assignments and grades have been entered into the system. Additionally, each user has a name, address, and e-mail. There are currently no empty tables in the system, meaning that each account will have access to a dierent dataset than other accounts.

Our audit plan was very limited since before the attack phase, we didnt have enough information how other teams implemented their secure database systems. Even after all the other teams published their attack instructions, We have little knowledge of what security measures were in place. Having said that, we tried to brainstorm common attacks on database system while not being very specic to keep our audit plan more general. Here is a rough plan on how we are going to approach that: 1. hardware penetrating

8.

THE ATTACK PHASE

In this section, we will be discussing matters of the attack phase. This includes how we prepared our system to be attacked by other teams, how we attacked other teams, and what actions we took in response to other teams attacks on our system.

2. SQL injection 3. Abuse permissions (see if any user has more permissions than they need) 4. Try to perform unauthorized actions (i.e editing data that not supposed to be edited under the current users permissions) 5. alter schema or try to bypass data integrity checks

8.1

Preparing our System to be Attacked by Other Teams

We created a new vApp on RLES and created two identical VMs within that vAPP, one for each team. We shared that newly created vApp with the other teams instead of sharing the vApp that contains the DBMS to prevent physical access to the DBMS. Other teams will attack our system incrementally in three separate phases. First, we will distribute student-level accounts, and the attacking teams will then report what data they were able to extract and possibly corrupt. This process

8.2.2

Attack on team 2

Because we were only given a chance to access their system via a web-based application, we were not able to review their design and thus we could not perform a full security audit on their database system. We just tried to attack team 2 web application to see if we would be able to break the condentiality, integrity and availability of their database system.

For the condentiality; we tried to compromised all the users that were given to us by team 2, but we were unsuccessful to do so. We were also not able to create our own a fake account so that we could perform any illegal money transaction on their banking system. For the integrity; we tried to inject client-side code in their web application, and by that we were able to prevent users from seeing a complete list of other users with whom they could do money transfer. For the availability; we tried to alter their team 2 web interface to the extent that in order to access the amount submission form, users needed to scroll down the webpage, thus making it hard for users to easily locate what the part of the webpage they were looking for.

for each user will have to be re-added. This can be streamlined, however, by setting up procedures that take care of the permissions. It is still more work than what might be in other implementations, but if security is desired, then considerable work will have to be done.

9.

LESSONS LEARNED

8.2.3

Attack on team 7

While performing dierent attacks on team 7, we tried tried the following: Unauthorized Actions, Abusing Permissions and nally Hardware Penetration. For unauthorized actions; we logged into team 2 database using our MySQL Workbench software with usernames and password provided to us by team 7. When successfully logged into their database, we tried to perform some queries like create, select, insert, alter, update, drop using the different users that they gave on their server, but we gured out that whatever query we tried to run against their server was denied. This showed us that permissions were well set on each user. For abusing permissions; we rstly tried to make changes on the views like deleting or altering but we were not successful in doing so. We tried to run views on dierent users and we gured out that some users were able to view their own records but they were also able to view records of some other users. For example; doctoruser was able to view his own records and view other doctors records as well others the records of nurseuser. For hardware penetration; we were given direct access to the server that contained the database and we seized this opportunity and bypassed their security on the server by enabling the skip-grant-tables option in the my.cnf le and thus we tried to extract all data from their database. At this level, if we were like other attackers in the real world with bad intentions we would have been able to drop their database or delete it. And this would make the integrity, condentiality and availability compromised and their entire database would never be accessible to whoever they would like to give access to it and it would no longer be secured at all.

One thing we learned for sure; Security is never served on a golden plate. It can cost a lot, and even with all security measure in place, it can still be awed. Dierent set of eyes can denitely help in discovering issues with any database system as we had discovered when team 4 pointed out the parameter mismatch in one of the procedures. All of that aside, if a good plan was carved out at the very beginning and a strong foundation of security was implemented with a vision to the future enhancement and development, database systems can be much more secure than a system that repeatedly gets patched. This is analogous to a car that gets body work too many times that at some point it will be worthless to do any more work to it. Too many xes on a system can render the system insecure and worthless if those xes were not done right.

10.

CURRENT STATUS AND FUTURE WORK

The journey for a secure database systems is a never ending journey. There will be no database system that is going to be perfect, and thus, to keep our system secure, we will have to keep updating our security measures to keep up with security trends in the database world. Some of the future work we have planned includes ltering all the database errors that are passed to the client to prevent any malicious attacks. We are also looking into streamlining the process of adding permissions to users instead of manually having to add those every time a change is due in the schema or procedures. We will need a wiki page for our Database administrator to provide a checklist of things to be done if such DDL changes are required. We are also looking into extending our Java client to feature a more friendly user interface instead of the command line interface. We will also keep enhancing the security of our database system by implementing various features from security literature.

11.

CONCLUSION

8.3

Actions Taken Due to Attacks on our System

We had a problem with one of the procedures where the specication we made stated that it takes only two parameters while it was implemented to take four parameters. Group 4 brought that into our attention and we immediately xed that and re-added the permissions for the users. Group 5 suggested that we should catch all the database errors and ltering it so that users connecting through the client will not see more information than they need. This is a great suggestion from a security standpoint and will be added to our future work section. Group 5 also mentioned that our database system is secure, but it can be hard to maintain with a few dozens of users. That would actually be true especially when changing the schema and adding/modifying procedures as permissions

This project has taken our perception of database security to a whole new level. The security of databases doesnt mean only physically securing the machine on which the DBMS resides, but also securing the data and the channels the data ow through. It also includes making sure insiders have enough and just enough permission to do their job without compromising any data whether sensitive or not. Our database system has performed very well during the attack phase and no sensitive data were compromised during that phase, which made us even more condent about the security of our implementation. On the other hand, this should be a great motivation for us to further enhance the security of our system and challenge people to exploit our system and the data in any way possible. This project implementation can be used as a strong foundation and a great start for any startup company looking to build their own secure database system. We had so much fun working on this project and working with other teams during the attack phase. We have denitely learned a lot from this project.

12.

RELATED WORK

14.

REFERENCES

In the paper Role-Based Access Control Models, written by Ravi S. Sandhu and Edward J. Coyne [7], the authors talk about things related to the policies we used when implementing our project. Role Based Access Control, or RBAC, is a set of predened roles and permissions that are given to users at their creation time. In RBAC, the administration is centralized, and the administrator is the one who gives the roles and permissions to all users, so that they can be able to perform specic tasks related to the nature of their job. When users have been given roles and permissions using RBAC, they are given these roles and permissions using the least privileges principle, which means that no user can perform a task that is not dened in his/her job prole, and he/she cant access content that is restricted to users with higher privileges. In RBAC, the administrator is the only one allowed to make changes to the database schema; no other user can have access to it and no user is allowed to change their own permissions or others roles and privileges.

13.

ACKNOWLEDGEMENTS

This paper is the result of the following interesting literature: [1, 2, 4, 5, 3, 6, 8]. We used all of these references to develop our understanding of a secure database system. Please refer to them for more information on the security features we implemented and more.

[1] R. Ben-Natan. Implementing Database Security and Auditing (5th Edition). Digital Press, Burlington, MA, USA, 2005. [2] E. Bertino and R. Sandhu. Database security-concepts, approaches, and challenges. IEEE Transactions on Dependable and Secure Computing, 2(1):219, 2005. [3] D. Ferraiolo, R. Kuhn, and R. Chandramouli. Role-Based Access Control. Artech House, Norwood, MA, USA, 2003. [4] S. Jajodia and T. Yu. Basic security concepts. In T. Yu and S. Jajodia, editors, Secure Data Management in Decentralized Systems, volume 33 of Advances in Information Security, pages 320. Springer US, 2007. [5] X. Jin, R. Sandhu, and R. Krishnan. Rabac: Role-centric attribute-based access control. In I. Kotenko and V. Skormin, editors, Computer Network Security, volume 7531 of Lecture Notes in Computer Science, pages 8496. Springer Berlin Heidelberg, 2012. [6] D. Little and S. Misra. Auditing for database integrity. Journal of Systems Management, 45(8):66, 1994. [7] C. E. F. H. Sandhu, R. S and C. Youman. Role-based access control models. Computer, 29:3847, 1996. [8] J. Shi and H. Zhu. A ne-grained access control model for relational databases. Journal of Zhejiang University SCIENCE C, 11:575586, 2010.