Build It

Getting Started

All implementations must be written in C. You will find some starter code in the Build It AutoLab assignment. Feel free to make whatever changes you feel are necessary, as long as you stay within the rules. You don’t need to feel obliged to keep the starter code the way we gave it to you; it’s just there as one suggested way of organizing your code.

Program Specifications

Your team will design a log format and implement both logappend and logread to use it. Each program’s description is linked below (and in the Table of Contents).

The logappend program appends data about activity in the museum to a log.
The logread program reads and queries data from the log. logread contains a number of features that are optional. If you do not implement an optional feature, be sure to print unimplemented to standard output.

Look at the page of examples for examples of using the logappend and logread tools together. Both tools must function correctly without Internet access.

As with most English-level specifications, you may find ambiguities or underspecified corner cases in the specs above. In all such cases, the Oracle reference implementation (described below) is the definitive authority. In other words, your implementation is expected to match the Oracle’s behavior in every particular.

Oracle

An oracle reference implementation is provided to demonstrate the expected output of a series of commands run on logread and logappend. You may run the reference implementation by submitting a query to the “Oracle” assignment in AutoLab. This is not a real assignment and will not be graded. It is only there to provide easy access to the reference implementation.

The oracle assignment expects you to submit a JSON file. Please check the formatting of your JSON file before submitting (for instance, by using https://jsonlint.com/ to ensure that your submission is a valid JSON file). The contents should be an array for commands (written as strings), along with an optional batch file. Here is an example:

{
  "commands": [
    {
      "program": "logappend",
      "args": ["-K", "secret", "-T", "1", "-G", "GERDA", "-A", "log"]
    },
    {
      "program": "logappend",
      "args": ["-K", "secret", "-T", "2", "-G", "GERDA", "-A", "-R", "16", "log"]
    },
    {
      "program": "logread",
      "args": [ "-K", "secret", "-R", "-G", "GERDA", "log"]
    }
  ],
  "batch": "LUsgc2VjcmV0IC1FIGVtcGwgLUEgbG9nCg=="
}

If you include the “batch” key, the value must be a base64 encoded batch file. To encode a file, most Unix/Linux/Mac systems include the base64 command, which you can run as:

base64 -i input_file -o output_file

The value of the “batch” key will be base64 decoded and placed in a file called batch when tests are executed. To run this batch file, you still need to specify a logappend command referring to the file using the -B flag, when specifying your list of command entries.

After submitting your query, you can then look at AutoLab’s output to see what the oracle produces.

Security Model

The system as a whole must guarantee the privacy and integrity of the log in the presence of an adversary who does not know the authentication token. This token is used by both the logappend and logread tools, specified on the command line. 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 guests, employees, 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.

Deliverables

The Build It assignment on AutoLab expects you to upload a tar archive of your implementation files (please do not upload any binaries or other intermediate files). To create such a submission, if you have used the Makefile provided with the starter code, in the directory containing your implementation’s files, simply run:

make handin

To score a submission, AutoLab will run tar xf handin.tar followed by make. The only requirements on make are that it must function without internet connectivity, and it must build from source (committing binaries is not acceptable).

Once make finishes, logread and logappend should be executable files within the build directory. An automated system will invoke them with a variety of options and measure their responses. The executables must be able to be run from any working directory.

Each test must complete within at most 60 seconds, and the entire build plus test process must take less than 7 minutes or your submission will time out, so try to avoid any obvious inefficiencies in your build and implementation.

Your code will be run within a Docker container on the server. To help test your code (to ensure that you have the right versions of libraries etc.), you can use this Dockerfile. Instructions for how to use it are within the same file. Docker CE can be installed on your system by following the instructions here.

Checkpoint

To ensure you’re making progress on the assignment, we will have a checkpoint deadline. By this deadline, your team must pass at least one test in AutoLab. We recommend the first test, which closely resembles the example given above for the Oracle. You can then continue to refine your system until it’s time for the final submission described below.

Final Submission

In addition to submitting your code via AutoLab, you should submit a design document (PDF) to Gradescope. In the design document you should:

Describe your overall system design in sufficient detail for a reader to understand your approach without reading the source code directly. This must include a description of the format of your log file.
List three specific classes of attacks you have considered, and describe how your implementation counters these threats. (Where possible, please note the relevant lines of code for your defense.) If you were not able to completely prevent a threat you identified, you may still mention it. In that case, describe any partial mitigation you implemented and explain anything you wanted to implement but were for whatever reason unable to. Please be clear about distinguishing what you have implemented vs. what you would have implemented.
Do not forget to include your names, Andrew IDs, and team name in your document.

Grading

Build It will be worth 100 points

75 points for passing the automated correctness tests.
To receive full credit, your implementation must pass all of the basic tests and at least three of the optional tests.
- The checkpoint is worth 10 of these 75 points. To get these 10 points, your program must pass at least one basic test by the checkpoint deadline.
25 points for your design document.
- 10 points for your description of your approach.
- 5 points each for your explanations of how you defend against a class of attacks.