Project 1: Mandatory Access Control for a Temporary Agency

For this project, you are asked to implement a mandatory access control system supporting data management at a temporary agency. The main concern is confidentiality of strategic plans of clients. Some of this is obvious - for example, a temporary who went to work for one company shouldn't then go to work for a competitor. But even knowing staffing requirements could cause problems -- knowing that Oracle is hiring a lot of database security experts could tell Microsoft something about what they will need in the next generation of SQLServer. As a result, someone at the agency who knows the specialties of temps who have been sent to Oracle shouldn't be able to write to documents that go to Microsoft.

You should consider the following types of subjects and objects in the system:

Subjects:

Company: 

Requests temps, makes payments to the temporary agency. Companies belong to competitor sets; we must make sure information does not flow from one company in a set to another. A company may belong to multiple competitor sets.

Contractor: 

Works (temporarily) at a company. Has a resume, gets paid.

Employee: 

Works for the temp agency. Note that the temp agency can also use contractors; they would be considered to have seen data about the companies they have worked for.

Objects:

Resume: 

Contractors write resumes describing their capabilities. These may need to be read by companies, as well as agency Employees.

Staffing Request: 

Companies create staffing requests describing their needs. These are read by agency Employees.

Time reports: 

Contractors write time reports, these are read and approved by companies and then read by agency Employees.

Invoices: 

The agency must send invoices to be read by companies; these are written by Employees.

Payments: 

Payments are sent by companies to the agency in response to invoices.

Paychecks: 

Agency Employees write paychecks that are given to Contractors.

Task

You must create a system that allows the necessary reading and writing of objects, and ensures that no information flows between companies in competitor sets. You should represent objects as files in a file system, and subjects as user IDs in the operating system. You should write scripts/programs that allow reading and writing appropriate objects. You don't have to worry about how reading and writing is done; something as simple as the unix cat command (possibly with an argument describing the type of the object) is sufficient.

A key component of this project is that you must not only implement a solution, but you must be able to argue that your solution meets the requirements. To do this, you will need to clarify/formalize/model the requirements, and argue that your system satisfies these requirements.

Teaming

This project should be done in teams of two to three members. Please email your team to the teaching assistant by 2pmEDT 13 October. If he does not receive information by that time, we will assign remaining people to teams by 9am on 14 October.

Timeline

This will be due in two parts. The first is an overall design document; this will be due Monday, 18 October (although earlier submission will result in earlier feedback.) The final project implementation will be due Friday, 29 October (we are considering making it due 5 November, but in this case we will have the next written assignment underway before the project is due.)

What to turn in

Design Document (18 October)

• High-level overview of the requirements and approach (at most one page)
• Discussion of how you will show the system meets requirements (1/2 page)
• Task breakdown between project members

Final Project (29 October)

• Source code suitable for archival
• Discussion of requirements and why those requirements satisfied (1-3 pages, the more formal the better.)
• Test script demonstrating that system works as intended.
• Schedule a demo with course staff.

This page last modified