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, users role 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. 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.

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.

2.

ARCHITECTURE AND DESIGN CONSIDERATIONS

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

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

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.

3.3

Client Application

Figure 1: Design Diagram (PNG).

We have not yet created a client application for users to access the database. All our development has been done through the MySQL workbench. The client application is in our future plans.

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.

4.

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.

4.1

Access Policy

3.

IMPLEMENTATION

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

3.1

Hardware

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 because of 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..

3.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

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. 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). The latter has not yet been fully implemented and is part of our future plans. We use views to further restrict access to the database, through Fine-Grain Access Control (schema-based permissions unfortunately do not provide enough granularity). We have created four dierent views for the four dierent users of our database. The rst view is student view, the second view is instructor view, the third view is the registrar view and the fourth and last view is the admin view. We created a view for the students, in the school database to allow them to view any information related to them, but we didnt allow change informations on which the dont have

privileges. The students view was implemented by verifying the studentId, personId and gradeId. The views are currently not fully tested, and as such they should be considered to be a beta feature at this point in the project.

4.2

Logging

The main new feature that we added during phase one of the project was activity logging/auditing. 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. 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 Thanks to items 3, 4, and 6, data 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 includes testing the DBMS as well as hardening our Windows server, and ensuring that our views are complete. Finally, we are planning on added a deleted column to the class, grade, person, and assignment tables so that we can revoke the DELETE permission from all the roles. There are certain data integrity considerations which need to be considered before such a eld can be added, however, which is why are postponing this feature until the next phase. Before submitting our system for cross-team attacks/testing, we will need to add additional users to the DBMS and create a row in the Person table corresponding to each user.

4.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. We also have future plans on improving the security of the server machine. Refer to section 4 for future plans relating to this subsection.

4.4

Data Integrity

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.

5.

FUTURE PLANS

We have already made signicant progress on our secure database system, and thus our future plans are currently very limited. As we implement these nal features, however, we may decide to add even more security features or hardening steps. First, we need to create a client application which will allow users to log in to and access our database. While the MySQL workbench could also be used for this purpose, the tool is too generic and wont allow others to properly test our database. We also need to perform a full audit of the security of our database to verify that all of our policies are working as designed, and that there are no known holes in the system.