Assigned: October 25, 2004
Security of Information is a critical issue in today's environment. Most organizations have policies that govern the use and flow of information, especially in digital forms. Typically, these policies are in English or some other human understandable language, and the expectation is that individuals in the organization will follow them. This leads to two kinds of security breaches. One is caused by a malicious insider -- someone who deliberately subverts security. The other, which is often more common, is caused by users who inadvertantly fail to follow policy. For instance, the policy could say that users should not connect to sites listed in a "blacklist" in order to prevent phishing attacks. However, due to clever use of URLs and redirections, the user could unsuspectigly be lead to such a site. One way to enhance security is to enforce the policy automatically, such that actions violating the policy cannot be taken by a user. For this project, you will be asked to add additional functionality to the Linux kernel that will allow this to be done. In particular, we'll ask you to enforce this for network connections, and you'll end up creating a kind of a firewall. Creating full policy enforcement systems can be extremely complex of course, so we ask you to do this very small subset of the total task.
The security policy will be stored in a file on disk in the root (/) directory in a file called
policy.txt. Please use the following file format:
port IN
port OUT
port BOTH
The file will contain a port number on each line, followed by in, out or both. in indicates that inbound connections should be allowed on that port, out permits outbound connections, and both will permit bidirectional connectivity. Your default policy should be to block. In other words, unless a port is explicitly mentioned in the file, you should deny access to it from both directions. For each port explicitly mentioned in the policy file, log the allowed/denied statistics. We encourage, but do not require, that you do this via the proc filesystem. You can always chose to log to a file instead.
There are many design issues which you should discuss in your project description. One such issue to consider might be how the information contained in the policy files will be loaded into the kernel. This can be done directly by the kernel code, or a helper program can be created in userland to assist. Another issue to consider is how actually implement the changes you are being asked to make (kernel module or direct modification of the source code). Please discuss your design decision in your project documentation. We don't ask you to consider the question of how such a policy should be designed, which will be critical in real life. We also don't ask you to describe mechanisms on how the policy file will get loaded. The papers in the references section of this handout describe some possibilities. Note that there are similar programs available on the net, and some functionality we ask you to develop might already exist in the linux distribution. You are NOT permitted to simply turn those in :-)
You will need to turn in all of your code, testing, and documentation using UMBC's blackboard system. In particular, turn in the tar/gzipped version of a patch to your modified kernel, any userspace programs which support your kernel modifications, your test cases/results, and your readme file.
The project is due by 11:59PM on December 14, 2004. In addition, your design documentation is due by 11:59 PM on Nov 8, 2004. Here are the guidelines for the design document. You are, of course, welcome to visit either the faculty or TA office hours for help. As usual, one of the first things we'll ask for is your design documentation. You may make changes to your design before your turn in the project. However, the design portion of your grade will depend heavily on the design document you hand in on Nov 8, 2004.
Your design documentation should be around five to six pages for a project of this size. It should include the basic design of your software (what module(s) will you write, where will you make changes to the kernel, what data structures you will use, how policy information will be communicated to your kernel code, etc.), a timeline, as well as details on the testing that you plan to do to ensure that your code works.
You are allowed to discuss ideas your classmates. No code exchange is allowed. If you use any external sources (like the Internet) you must cite them. You should also cite any discussions with other students, faculty, or anyone else who helped you in any way whatsoever. Academic dishonesty will be sternly dealt with.
The intent of the grading for the project is not to differentiate among those students who do a careful design and implementation of the assignments. Rather, the grading helps us identify those students who (i) don't do the assignments or (ii) don't think carefully about the design, and therefore end up with a messy and over-complicated solution.
Remember that you can't pass this course without at least making a serious attempt at each of the assignments. The grading is skewed so that you will get substantial credit -- even if your implementation doesn't completely work -- provided your design is logical and easy to understand. This means that you should first strive to come up with a clean design of your project on paper. Second, don't try to add fancy features because someone else is!
The grading for the project will be as follows: 30% design, 70% implementation. We have structured the grading in this way to encourage you to think through your solution before you start coding. If all you do is to work out a detailed design for what you would do to address the assignment (and if the design would work!), but you write no code, you will still get almost a third of the credit for the assignment. The implementation portion of the grade considers whether you implemented your design, ran reasonable test cases, and provided documentation that the TA could understand. Part of being a good computer scientist is coming up with simple designs and easy to understand code; a solution which works isn't necessarily the best that you can do. Thus, part of the design and implementation grade will be based on whether your solution is elegant, simple, and easy to understand.