Programming Problem: Secure Log File

Summary

The goal of this assignment is to implement a secure log to describe the state of a hospital in terms of the doctors and nurses who have entered the building and which rooms they are in. The log will be used by two programs. One program, logappend, will append new information to this file, and the other, logread, will read from the file and display the state of the hospital according to a given query over the log. Both programs will use an authentication token, supplied as a command-line argument, to authenticate each other; the security model is described in more detail below.

Programs

Students design the log format and implement both logappend and logread to use it. These programs must be written in C or C++ and must compile and run on compute.cse.tamu.edu. Each program's description is linked below.

• The logappend program appends data to a log
• The logread program reads and queries data from the log

Examples

Look at the page of examples for examples of using the logappend and logread tools together.

Security Model

The system as a whole must guarantee the privacy and integrity of the log in the presence of an adversary.

The adversary is able to:

• Execute logappend and logread.
• Create files and directories.
• Read the contents of files and directories.
• Modify the contents of files and directories except Makefile, logappend, and logread (see below).
• Remove files and directories.

The adversary is not able to:

• View the initial compilation of logappend and logread.
• Recompile logappend and logread.
• Modify the binary data of logappend and logread.
• Change directory above the one containing logappend and logread.

The adversary does not know the authentication token. This token, specified on the command line, is used by both the logappend and logread tools. Without knowledge of the token an attacker should not be able to:

• Query the logs via logread or otherwise learn facts about the names of staff members, room numbers, or times by inspecting the log itself
• Modify the log via logappend.
• Fool logread or logappend into accepting a bogus file. In particular, modifications made to the log by means other than correct use of logappend should be detected by (subsequent calls to) logread or logappend when the correct token is supplied

Oracle

An oracle reference implementation is provided to demonstrate the expected output of a series of commands run on logappend and logread. Students may run the reference implementation by going to ritchey.tk. Here is an example of the expected input for the oracle:

{
    "tests":[
        {
            "input":"logappend -T 1 -K secret -D ritchey -A -F log"
        },
        {
            "input":"logappend -T 2 -K secret -D ritchey -A -R 326 -F log"
        },
        {
            "input":"logappend -T 3 -K secret -N bregger -A -F log"
        },
        {
            "input":"logread -K secret -S -F log"
        }
    ]
}

Details

• Names are arbitrary-sized non-empty strings of alphabetic characters (a-z, A-Z) in upper and lower case. Names may not contain spaces. Names are case sensitive. Doctors and nurses can have the same name.
• The hospital staff is composed of multiple doctors and nurses. A complete list of the staff of the hospital is not available and staff will only be described when a doctor or nurse enters the hospital.
• Tokens are arbitrary-sized non-empty strings of alphanumeric characters (a-z, A-Z, 0-9)
• Leading zeros in room IDs should be dropped, such that 003, 03, and 3 are all equivalent room IDs.
• Timestamps are positive 32-bit integers specifying the number of seconds since the hospital opened.
• Room IDs are non-negative 32-bit integers.
• File names are non-empty strings of at most 255 alphanumeric characters (a-z, A-Z, 0-9), underscores (_), and periods (.). The full path of the file may contain forward slashes (/) to specify a file in another directory and may be at most 4096 characters.
• All log files and batch files must be located in the same directory from which logappend and logread are invoked, or in a sub-directory.
• The log file and batch file path on the command line must match the actual path to the file. Paths will be specified relative to the directory from which the programs are invoked.
• The log file cannot be present multiple times.
• Command line arguments can appear in any order. Each argument can only appear once.

Submission

• Students are strongly advised to initialize a git repository on github.tamu.edu.
• Create a directory named requirements in the top-level directory of your submission and place your requirements documentation in that directory.
• Create a directory named tests in the top-level directory of your submission and place your tests in that directory.
• Create a directory named build in the top-level directory of your submission and place your code in that directory.
• Your directory should look like this:
  

  ├─  secure_log
  │  ├─ build
  │  │  ├─ Makefile
  │  │  ├─ *.c
  │  │  ├─ *.cpp
  │  │  ├─ *.h
  │  ├─ requirements
  │  │  ├─ *.pdf
  │  ├─ tests
  │  │  ├─ *.json

• At each checkpoint, submit a .tar.gz file that contains your submission directory (e.g. tar --exclude=".git" -czvf secure_log.tar.gz secure_log/)
• The requirements will be graded by human readers (i.e. Instructor and TA).
• The tests will be graded against the oracle implementation for correctness. Completeness will be assessed using code coverage (see coverage testing with gcov).
• To score a submission, an automated system will first invoke make in the build directory of your submission. Once make finishes, executable files logappend and logread should exist within the build directory. An automated system will invoke them with a variety of options and measure their responses.
• make must function without Internet connectivity.
• make must return within five minutes.
• make coverage should create the executables compiled with flags -fprofile-arcs -ftest-coverage.