6.858 Fall 2010 Lab 5: Final project
| Proposals due: |
Friday, November 12, 2010 |
| Presentations due: |
Monday, December 6, 2010 (in class) |
| Code and write-up due: |
Friday, December 10, 2010 (11:59pm) |
Introduction
In this lab, you will work on a final project of your own choice. Unlike
in previous labs, you may work in groups of 2 or 3 for the final project.
You will be required to turn in both your code and a short write-up
describing the design and implementation of your project, and to make
a short in-class presentation about your work.
Below are some ideas for final projects that you might use as inspiration,
including some of the projects from past years.
We encourage you to come up with your own ideas for what you would like to
work on; don't restrict yourself to this list.
- Add sandboxing support to Python, so that it's possible to import
an untrusted Python module without giving it full access to your
system or your application. The Java security architectures paper
should be helpful here, and Python already provides some basic memory
safety guarantees (although you might need to implement some mechanism
to restrict introspection).
- Use DynamoRIO's binary instrumentation to implement some cool security
mechanism for unmodified binaries. For example, you could implement a
binary-level taint tracking system, similar to
Resin, that prevents
secret files from being sent out over the network.
- Implement Resin-like taint tracking for Java, perhaps using bytecode
rewriting.
- Find an interesting use for trusted hardware, and figure
out how to expose trusted hardware safely to applications.
Linux should already have a basic device driver for a TPM.
- Build an XFI-like system for Linux kernel modules or packet filter
code. You could look at Native
Client as another example of a system that sandboxes x86 code.
- Build tools to find common vulnerabilities in programs of your choice
(e.g., C code, PHP, Python, etc). There are several existing frameworks
on which you could start building, such as
sparse
and LLVM for C code, or
PQL (the tool from the Java
static analysis paper) for Java.
- Write a tool to help privilege-separating PHP applications.
- Evaluate how hard it is to privilege-separate a real application
like phpBB.
- Implement more flexible protection mechanisms for Linux (so that any
user can create additional protection domains -- sub-users -- to run
code with less privileges, without having to be root). You can build
upon a class project from last year,
UserFS.
- Based on Google's caja
library, sandbox existing Javascript mashups/applets (what to do
about existing uses of globals in the Javascript environment?)
- Write a browser plugin to prevent cross-site scripting attacks when
both the server and the client are following some rules (e.g.
explicitly annotating privileged JS code). Bonus points for
allowing untrusted JS code using something like caja!
- Implement an encrypted file system with plausible deniability (i.e.
where there can be multiple encrypted file system images within a
single FS, and without the right password, you don't know if unused
blocks are free or part of another encrypted FS you don't have the
password for.) See paper on
deniable file systems and
TrueCrypt.
- Auditing support for web applications.
For instance someone broke into your blog or forum, added a user
account for themselves, changed permissions, and posted garbage messages,
you may want to track down all of the changes made by the attacker.
Could be done with the help of a language runtime, such as Resin.
- Explore the extent to which covert channels / side channels matter,
e.g. in shared VMs like EC2, vs. shared OS, vs. other environments.
See this paper for
some background information.
We encourage final projects that combine some ideas you have learned in
6.858 with other classes or projects you are already working on. For
example, implementing some aspects of a capability design from KeyKOS
in the JOS kernel from 6.828 might make a good final project that you
could use in both classes. Extending some system you are already working
on to add better security mechanisms would also be a good candidate project.
Several final projects from last year's class ended up being subsequently
published as research papers
(e.g.,
UserFS
and
BStore).
If this sounds interesting to you, try to pick an ambitious class project
that you might want to continue working on afterwards!
There are three concrete steps to the final project, as follows:
Decide on the project you would like to work on, and the other students
you would like to work with in a group.
Discuss your proposed idea with course staff over the next week,
before the proposal deadline, to flesh out the exact problem you
will be addressing, how you will go about doing it, and what tools
you might need in the process. By the proposal deadline, you must
submit a one-to-two-page proposal describing the problem you want to
address, how you plan to address it, and what are you specifically
proposing to design and implement.
Prepare a short in-class presentation about the work that you have done
for your final project. We will provide a projector that you can use
to demonstrate your project.
Write a document describing the design and implementation of your project,
and turn it in along with your project's code by the final deadline.