Assigned: 29 Jan 2003
We assume that you are already familiar with makefiles and debugging from classes such as CMSC 341. If not, this will be a considerably more difficult project because you will have to learn to use these tools as well.
We ask you to implement a two new system calls, setmykversion and getmykversion. The former should set the value of a kernel variable called kv421 to an integer that you pass, the later should return the current value of kv421 in an integer variable that you pass to the function as an argument. The function itself is fairly straightforward, but there are several minor differences between writing a kernel function and a regular user space function. We provide some hints below. In addition, you'll need to write a regular program in user space that will prompt the user to give a value, set the qv421 kernel variable to it, read it back, and write it on screen. In effect, a simple driver program to show that your system calls work.You will need to hand in all of your code and documentation using the submit programs available on the GL cluster. In particular, hand in the tar/gzipped version of a patch to your modified kernel, your driver program, and your readme.
In addition, your design documentation is due one week before the final due date, by 11:59 PM on 7 Mar 2003 . We are enforcing this deadline to ensure that people don't leave the project until the last minute. You are, of course, welcome to visit either the faculty or TA office hours for help; however, one of the first things we'll ask for is your design documentation (unless you're asking for help with that...). You may make changes to your documentation before the full phase 2 handin; however, the design portion of your grade will depend heavily on the design document you handin on Mar 7th.
Your design documentation, typically 1-2 pages for a project of this size, should include the basic design of your software (what modules will you write, where will you make changes to the kernel etc.), a timeline, as well as details on the testing that you plan to do to ensure that your code works.
The assignment name to use with submit for the documentation is p1doc, and for the project code is p1code.Now comes the real stuff! In this phase, you will implement a rudimentary intrusion detection system in the kernel. Attacks on computers are a very significant problem today, and likely to grow worse in the future. Intrusion Detection Systems (IDSs) seek to detect attacks and possibly take remedial action.
There are several different ways of doing this. One interesting approach keeps track of system calls. In particular, the idea is that when someone "rootkits" a computer or subverts an existing process using say a buffer overflow, this can be detected by looking at the system calls the process makes and comparing it to the calls that a "healthy" process would make. A healthy process will typically exhibit a small set of behaviors. Each of these behaviors can be characterized by a "usual" sequence of system calls. A naïve way to do this is to see if a system call was made by a process that it does not make.
More interestingly, we could build a "reference log" of normal sequences for the process. Given a stream of system calls made by the process, a sequence is a group of system calls in the stream as seen from a fixed sezed window. Consider a sample stream of system calls: open(O), read(R), mmap(M), write(W), close(C).
O R M M W R C
This stream as seen from window sized 5 gives following sequences.
O R M M WIf we could construct a reference log for the particular environment, process behavior can be monitored for aberrations. In particular, a sequence that is not in the reference log indicates an aberration. Experimental evidence suggests that short sequences of system calls (of length six or more) provide a signature for normal behavior and that signature has a high probability of being perturbed during intrusions.
In this project, we will implement a simpler scheme. You will instrument the interrupt dispatcher so that each time a system call is made, you will log the pid of the calling process and the actual call made. Write a separate user space process that will monitor this log and compare it with the reference logs of each process. (Construct a reference log by observing the process in healthy state. There are various ways to store the logs e.g. flat file, database etc.). The user space process will look at the last 'k' entries in the log. If a particular system call is made in this window, you will set the bit corresponding to that call to '1'. You must decide value of 'k' that you will use.
Remember that a healthy process will not exhibit exactly the same behavior as in your reference log i.e. the exact system calls made will vary slightly. So in order to avoid false alarms, we must decide if the current sequence is aberrant enough to be classified as intrusion. Thus we need to define "distance" between two sequences. If the distance between the observed sequence and sequence in the log crosses some predefined threshold, then we can flag an intrusion. One simple way to define distance between two sequences is Hamming Distance. The Hamming distance between two ordered sequences is the number of places where the sequences are not identical. e.g. distance between 1010 and 0101 is 4 while distance between 1011 and 1101 is 2. For our purpose, consider a reference log where open, read, write, mmap and close (1, 1, 1, 1, 1) and observed log with open, read and close (1, 1, 0, 0, 1). The hamming distance between these two logs is 2.
For extra credit (20 %), build the system described in Intrusion Detection using Sequences of System Calls . You may implement other systems described in literature after verifying with Dr. Joshi
You will need to hand in all of your code and documentation using the submit programs available on the GL cluster. In particular, hand in the tar/gzipped version of a patch to your modified kernel, your user space intrusion detection program, and your readme. See apache testing for how to test your implementation.
In addition, your design documentation is due by 11:59 PM on April 6, 2003. 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 documentation before the full phase 3 handin; however, the design portion of your grade will depend heavily on the design document you handin on April 2nd.
Your design documentation should typically be 5-6 pages for a project of this size. It should include the basic design of your software (what modules will you write, where will you make changes to the kernel, what data structures you will use, which format will be used for storing the logs etc.), a timeline, as well as details on the testing that you plan to do to ensure that your code works.
The assignment name to use with submit for the documentation is p2doc, and for the project code is p2code.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. Further, 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 some other group is!
The grading for the project will be as follows: 40% design, 60% 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 half 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.