CMPSC 497 - Project #4 - Authorization Checks

Due Date: Th April 26, 2018 at 11:59pm.

In this project, you will implement a reference monitor for your server program.

Inputs: You will be provided with implementations of three operations to be associated with the three function pointers of struct A in a file called cmpsc497-ops-X.c, where X is the number of your format file from the previous projects. The aim is to add a reference monitor to enforce expected access control policies for your server over these operations. You will need change the header file reference in this file from #include "cmpsc497-format-X.h" to reference your format file from Projects 1 and 2.

In addition, a tarball is provided for the project for the example format files from Project 1. These are provided as an example of a shell of implementation. There are three things you need from the tarball.

  1. The Makefile has been modified for this project. Please use the Makefile from the tarball.

  2. The file cmpsc497-kvs.h has been modified slightly. You can replace your old version of this file with the one provided in the tarball. The difference is the addition of a third KVS for storing authorization policies.

  3. The beginning of the file cmpsc497-main.c has been modified significantly. Just the beginning of that file is provided in the tarball. The functions main and get_object are modified. You need not change code in these.

    main now includes a third command "pol" for setting authorization policies by calling a function set_policy, which reads the input file to add authorization rules to the Policy KVS as described below.

    get_object has been changed to provide three "get" operations: get0, get1, get2. Each of these operations invokes a function pointer on a struct A object.

    Please set the OBJ_LEN define to the object length for your objects from Project 1. Otherwise, the objects will be the wrong size.

    Please add the remainder of your code from Project 2 for the rest of this file.

Lastly, you will be provided with requirements for the access control policies that you will enforce. More details on those requirements and how use them to complete the project below.

Project Tasks: Please complete the following tasks for the project.

Task 0 - Setup: Add code to set the function pointers in struct A (see cmpsc497-format-X.h for the definition) to the corresponding functions in your operations files (see cmpsc497-ops-X.c) when objects of struct A are created, probably be set_object (for "set") and unmarshall (for "get").

Add the following code to your cmpsc497-format-X.h file from Project 2 for struct A.

int (*op0)(char *username, char *owner, struct A *objA);
int (*op1)(char *username, char *owner, struct A *objA);
int (*op2)(char *username, char *owner, struct A *objA);

As in Project 3, you will need to set the function pointers for these function pointer fields to their respective function_X functions in set_object and unmarshall to enable these functions to be invoked.

Also, please update the Makefile to set '0' to your format file value in cmpsc497-ops-0.o references in that file.

Task 1 - Install Authorization Policies: Complete the implementation of set_policy, which takes a file with authorized operations, and adds those authorized operations to the Policy KVS. Each authorized operation entry (one per line) is of the format: "[username]:[obj_owner]:[op]", where: (1) [username] is the name of the user making the "get" request; (2) [obj_owner] is the owner of the object retrieved from the KVS for the operation; and (3) [op] is the name of the operation. For operations, I suggest using Ax, Bx, and Cx for operation names where A refers to the structure accesses and "x" is a number to differentiate multiple cases.

In this function, you will add an entry for each policy entry to the Policy KVS consisting of three entries. The "key" will be an authorization entry above. The "value" will be the result of the authorization check (return value of the authorize() function) - allowed (1) or not (0). The "tag" is not used, so you can set to any value.

Task 2 - Implement Authorization: Add code to cmpsc497-ops-X.c to implement your authorization check in the function authorize. Calls to authorize will mediate the operations (function_*) in cmpsc497-ops-X.c to enforce the access control policy. To do the authorization check, you must build an authorization query in the function_* functions to match a "key" in the Policy KVS (if there is an entry for that query). You will use the key to retrieve the authorization "value" (authorized (1) or not (0)). If there is no match for the query, we assume that the authorization response will be 0 (unauthorized) from authorize.

Please print the authorization query and response value for each call to authorize. That is how I will check where you placed your hooks.

Task 3 - Produce Non-Redundant Authorization Hook Placement: First, identify where authorization hooks must be placed to provide complete mediation of each object that does not authorize redundant sets of structure member accesses. From the slides on April 5 and associated reading, a hook is needed for every security-sensitive operation (SSO), where an SSO is a set of statements associated with a "choice" made using untrusted input that includes structure member accesses to security-sensitive objects.

There are three types of choices to mediate: (1) when the program retrieves an object from a container data structure using untrusted input (e.g., a "get" request); (2) when an object is extracted from a field of a object that satisfies (1) directly or indirectly; and (3) when a branch that performs structure member accesses to an object from (1) or (2) follows a conditional that depends on adversary-controlled input. For this project, assume that the object data is potentially adversary-controlled.

In this step, the aim is to remove all redundant hook placements. We say a hook is redundant if it authorizes structure member accesses for a specific variable and field that have already been authorized. Identify where non-redundant calls to authorize would be placed by a comment in the code that includes the phrase "non-redundant hook."

NOTE: Please place these hooks as late as possible, but preceding any unauthorized structure member access.

Task 4 - Produce Minimal Authorization Hook Placement: Place the minimal number of authorization hooks (actual calls to authorize) necessary to enforce the requirements for authorization policies. I will provide each student with their requirements for their server code.

Each requirement states expresses the policies that must be enforceable using the placed hooks. You should remove a hook for an SSO only if all the unauthorized subjects for that operation must always have already been blocked by a prior hook for all program executions.

NOTE that you may further reduce the number of hooks if the hooks on all branches enforce the same policy. In that case, a single hook before the conditional to enforce the expected policy is sufficient.

Submit all the project code necessary to build and run your project.

Ensure that your code runs correctly on machines in the in the CSE Linux Lab. Any one of these machines will be sufficient - cse-p204instXX.cse.psu.edu, which XX is a 2-digit number from 01 to at least 40.

There will be a dropbox created on Canvas to submit your code, input, and README to the Canvas dropbox by 11:59pm on Th April 26, 2018.

You are to complete this project only with your team members. We will create a Piazza forum, and the only allowed sharing of project information is through that forum. Do not discuss this project with anyone outside of Piazza.


Trent Jaeger