General Instructions. Students are required to work in groups of 2 or 3 for this assignment. The group may have a different composition from your group for previous assignments. An assignment submitted on behalf of a "group" having only one student will receive a grade of F. All members of the group are responsible for understanding the entire assignment.
No late assignments will be accepted.
Academic Integrity. Collaboration between groups is prohibited and will be treated as a serious violation of the University's academic integrity code.
Each bank employee has a unique userid. We assume that the set of userid's has been specified (realizing that any real system would also provide a way to add and delete userid's when bank employees join or leave). Different employees are permitted different access to the various pieces of customer data that is stored: the customer's name, address, social security number, employer, and annual income as well as the account's type (checking or savings) and balance. In addition, we would expect that access by a customer using an ATM would be restricted to reading and/or making certain modifications only to accounts owned by that customer.
In this assignment, you will contemplate one or more plausible authorization policies for this bank setting and then implement mechanisms to enforce such authorization policies. Restrict your concern (and energies) to attacks that are launched either through the teller terminal or through the ATM. In particular, do not worry about passive or active wiretappers; do not worry about attackers reading the memory of system hosts.
Some Plausible Policies. Many useful access control policies security can be described in terms of an access control matrix and commands that transform the matrix. For our bank, each row of the matrix (i.e., subject) would correspond to an employee's userid or a customer; each column (i.e. object) would correspond to a piece of customer data.
Give three or more specific examples of discretionary access control policies for the bank. Describe each example policy by discussing sensible restrictions on what rights should appear where in the matrix and (if necessary) discussing operations to change the matrix (including some indication of events at the bank that should cause each of these operations to be performed). Among your example policies include at least one that admits the possibility that rights in the access control matrix change. Your own personal experience with real banks and business---with their hierarchical management structures and widespread practice of assigning customers their own "private" representatives---can inspire you in formulating security policies that would protect customer privacy, data integrity, and make it difficult for dishonest employees to steal from customers.
Enforcing Plausible Policies. Extend some version of our banking system that already supports the functionality required by Phases I and II (you may use (i) the system that you produced, (ii) one produced by other students in the class, or (iii) the sources, .class files, and documentation that we have posted on the web in \\Goose\courses\cs513-sp00\phaseIIIgoodies) to enforce access control policies. Use access control lists, capabilities, or any other technique that seems appropriate for storing the information in a protection matrix. Schemes that support wider classes of policies will receive higher grades. Here are interesting benchmarks:
The most basic enforcement mechanism will implement a single (interesting) static policy. Thus, the policy will be "hard-coded" into the enforcement mechanism and the protection matrix will not change during execution. More advanced mechanisms implement a policy in which the protection matrix does change over time---this is likely to require adding a user interface (or extending the existing one) so that new functions can be executed from a teller terminal. The most ambitious solutions will allow a policy to be input before bank execution commences and would entail creating a "policy language" so that a system administrator can input a policy to the bank.
\\Goose\courses\cs513-sp00\proj04.submit
Don't be disturbed by warnings informing you that the file cannot be accessed after it has been copied.
Should you wish to revise your submission after you have copied it to our folder, then simply correct the files and re-copy the entire directory---but this time use the name xxxxx1. Revisions to that should be named xxxxx2, and so on. We will grade only the largest-numbered file of a series. No late submissions will be accepted.
Your directory should contain the following files (at least):
Don't underestimate what is involved in writing instructions for installing, compiling, and running your software. Do path values have to be set? Must the software be installed in a particular directory? Must the name of the host processor be put someplace? Use one group member's account to test your installation script. The easier it is to install your system, the more-kindly disposed the grader will be in evaluating your efforts.
Grading. Your grade will be based on the following elements: