CSE443 - Project #3 - Mandatory Integrity

Due Date: Tu April 10, 2012, 11:59pm.

This project examines different methods for protecting the integrity of processes and data using mandatory protection systems.

The goal of integrity protection is to prevent processes from receiving untrusted inputs and files from being updated by untrusted processes. However, allowing no interaction between trusted and untrusted processes prevents many useful interactions from occurring, so people of explored several different integrity policies. We examine three in this project.

  1. Biba integrity: In Biba integrity every process and file is assigned an integrity level, where the levels form a lattice (like MLS). In Biba, a process is only allowed to read a file only if its integrity level is the same or lower than the file (read-up). Also, a process is only allowed to write a file whose integrity level is the same or lower than the process (write-down). Exec is same as read.

    In this project, we only use a two-level Biba lattice (high and low).

  2. Windows Mandatory Integrity Control (MIC aka Biba Ring integrity): Because trusted processes are often designed to serve requests from untrusted processes, many operations are denied by Biba integrity. Windows has recently deployed an integrity approach called Mandatory Integrity Control (MIC) to prevent untrusted (Internet) programs from modifying more trusted files (system). However, MIC allows trusted processes to read untrusted files, taking a risk that programs protect themselves when using untrusted data. That is, a process can only write a file if whose integrity level is the same or lower, a process can only exec a file whose integrity is the same or higher. However, all reads are allowed.

    In this project, we use a three-level MIC lattice: Internet (lowest), user, system (highest).

  3. Low-Water Mark Integrity (LOMAC): An alternative approach allows a process to perform (nearly) any operation it requests, but reduces the integrity of the process when it uses untrusted data. Such a method is called Low-Water Mark Integrity (LOMAC), because it reduces the process's level to lowest integrity level of all the data that it has read or executed. Also, a file's integrity level is the lowest integrity level of any process that has written to the file.

    In this project, we use a two-level LOMAC lattice: low and high.

In this project, you will have to complete the code for a reference monitor that enforces a mandatory protection system that enforces these three policies (the policies will be provided). This reference monitor accepts policy files that express the protection state, labeling state, and transition state. You will need to add code to install part of the policy (labeling state) and provide some runtime enforcement. There will also be questions to answer regarding the system.

Follow these instructions:

  1. Obtain the tarfile from here.

  2. Unpack the tarfile in some appropriate directory on a UNIX system (there are many available at CSE -- see Notes below). You will only need this code and access to a debugger, such as GDB.

  3. You task is to complete four (4) programs: (1) addLabelPolicy in cse443-lattice.c; (2) labelProcess; (3) checkAccess; and (4) checkTrans in cse443-refmon.c. There are /* YOUR CODE */ comments in the files to guide you to implement the proper functionality.

  4. addLabelPolicy assigns a mapping from name to level based on the policy file's lstate statements. This is the labeling state of the reference monitor's mandatory protection system. It is assigned to the global variable label_mapping, which is a list of name-level mappings. In this function, you just need to find the lattice level object for the level provided from lattice, create a map object (defined in cse443-lattice.h) that assigns the level to the name, and add a new element (elt defined in cse443-list.h.

    At runtime, whenever name is a prefix of a user name or file name, the process or file, respectively, is assigned the associated level from the labeling state (label_mapping). The task of labeling is performed in labelFile (done for you) and labelProcess.

  5. labelProcess assigns a level to a process named proc using name from a mapping mapping. At runtime, every new process must be labeled when it starts. This is the function that applies the labeling state to produce such a label. Processes are created in two ways: (1) at login based on authenticated user name and (2) at process create (fork) time based on the parent process name. The difference is determined by the mapping passed into that function. You simply have to retrieve the level associated with that name in the supplied mapping and create a new level assignment for this process name proc. Runtime level assignments are stored in the global variabel system_mapping.

  6. checkAccess authorizes operations requested by processes. Operations include open (for read, write, and rw), exec, read, and write. All operations are on file names, including read and write (i.e., no file descriptors). The permissions required for the various operations are specified in execCmds in cse443-refmon.c. You have a few tasks to fill in: (1) retrieve the level assignment element for the process and file (procElt, fileElt) from system_mapping; (2) extract the level indices for the process and file (proc_level, file_level); and (3) add the code to check when read/exec or write are allowed. Note that reads are always allowed in MIC.

  7. checkTrans determines if the level of a particular process or file should be changed based on the transition state (tstate specifications in the policy). You have two tasks to fill in: (1) retrieve the level assignment element for the process and file (procElt, fileElt) from system_mapping and (2) retrieve a transition state entry for the combination of subject level, object level, and op, applying a transition if found.

  8. Test your code by running it over the three policies supplied in the tarball for Biba (e.g., biba.policy), MIC, and LOMAC. Run the program using cse443-p3 [policy] test [results]. The results must match those provided for Biba (e.g., biba.results), MIC, and LOMAC to get full credit. Note that messing with the print statements included in the code will cause your output not to match, which will cause your grade to suffer. DO NOT MODIFY THE PRINTF STATEMENTS.

  9. I will provide a drop box for submitting this project. The project is due on Tu April 10 at 11:59pm. Please attach a tar file containing all the source, including your additions. You can build this tar file using the command make tar from the source directory.

Notes

  1. You are to complete this on your own. Any sharing of code or help during the coding of this project is expressly forbidden. Do not discuss this project with anyone.

  2. A Makefile has been created to help you build the applications. Simply type "make" in the target directory to build the code.

Documentation

To perform this project, you will have to become familiar with the use of the GNU Debugger GDB.

Questions

  1. The transition state supplied causes processes to transition from low to high when exec uses a high file. Why is there no transition rule for fork?

  2. Why does biba.results show a denial of process p2 to read file f1?

  3. Why does mic.results show an allowance of process p2 to read from file f1?

  4. Why does mic.results show a denial of process p11 from exec on file f1?

  5. Why does lomac.results show that process p2 is relabeled to low prior to reading f1?

  6. Why does lomac.results show that process p2 can write f3 sometimes, but not others?


Trent Jaeger