CMSC 414 Fall 2002 Homework # 3 Due October 22, 2002 In order to receive credit, solutions still must be electronically SUBMITted by 12:00 Noon on the above date. Written Exercises: 1. Brief documentation of the design choices and implementation of the programming part. This should include, but not be limited to any questions mentioned during the in-class discussion of this assignment over the next two weeks. This is to be in a text file "Docs.txt" in the directory where your server resides. Programming Exercises: You must use Java, JDK 1.3.1 as provided by OIT. Additionally, you may use the JCE which Mr. Seong-Wook Joo has made available via the grading account (rf414001). See the class web page for directions on using this extension. As before, you should submit a tar file including the source code, the executable version, and all relevant documentation. Make sure that this tar file includes a saved state from your testing. See the other handout and/or the web page for format and usage specifications. If the problems below seem underspecified, make a reasonable, non-trivial assumption and proceed. State your assumption in the documentation, and attempt to justify it. To be polite, and not tie up all of the popular ports the night before the program is due, you may consider using sockets that are some function of the last 3 digits of your class account (1XXX, 1500 + XXX, etc). Assignment Overview: 1. You are to write an Access Mediation Server (called AMServer.java) which will handle user requests to access objects and determine whether or not the access request should be granted. You are to maintain an access control matrix and use it to mediate these requests. Your server will live in it's own directory, along with whatever support files you may require. It will mediate access requests based on both our original Bell-LaPadula (four levels, no categories or compartments) mandatory access control (MAC) model and the discretionary access control model discussed in class. We will suspend reality enough to assume that any ancillary files need not be encrypted, with the exception that no authentication information will be stored in the clear. I will give you specific names for the files I think that you need (such as: passwd.txt and acm.txt). You are free to use additional files, but do not forget to include them as objects in your ACM. This server must save state before exiting, and when invoked must have the option (supplied via command line) to come up in its previous state or to begin in a (specified) initial state. See format instructions for a sample initial state files. This is only a sample, you will need to be able to come up in various initial states specified by files of this format. The state includes the ACM, the list of registered users, and the authentication information. This server will respond to access requests by either stating that the access is allowed, or that it is not allowed and why it is not allowed. (you do not need to actually maintain the objects and deliver info (for read requests) or change the object (for write requests) with the obvious exception of your passwd.txt and acm.txt files. Secondly, the server will mediate and handle client requests (see # 2 below), and make the appropriate changes to the ACM and/or the password file. Thirdly, the server will mediate and handle requests generated by the privileged client discussed in # 3. This server is only required to deal with one client at a time, but it must remain resident for the next client after a client "logs out" or quits. 2. You are to write a client program (called GenClient.java), which will be able to contact the above server in order to make access requests. In order to partially justify some of the assumptions made above, this client may reside on a different machine than the server (so you must use accept a machine name from the command line (see format) rather than using "localhost"), and will be in a separate directory when you submit your programs. It should communicate with the server in a way that provides both secrecy and authentication. It should be a generic client, and store no authentication or identification information. In addition to requesting access from the server, some of the tasks that this client must be able to initiate include: logging on, changing password, changing DAC file permissions, creating new files, and deleting files. See the format handout (also on the web). 3. Enhance your generic client program to allow for a privileged client (userid: bossman). This client can perform to perform administrative (and grading) tasks via the server. Such tasks include: Outputting the ACM to standard out (or to a specified file), adding users, deleting users, and telling the server to exit and save state (and release ports!). Once again, see the format handout for the specifics. 4. You will also need an initialization program (call it Init.java, and put it in the directory with the server, you may assume that this one runs on the same machine as the server) in order to bring the server up in a specified initial state. Since you are not storing the passwords themselves (set A on page 366 of your text) but complementary information (set C), I have declared that it will be easier for you to provide an initialization program to populate the password file with this information instead of having to provide a hash function that is 100% compatible with one I specify. Since this requirement is solely for the purpose of making it possible to grade the assignment (e.g., allow me to bring everybodies server up in an identical configuration and run scripts to test it) you may state that such a program would not even exist in a real world application and thereby justify hardcoding a hash of this programs password within the server. The password for this program shall be: 1i2Lt*M and you need not provide a mechanism to change this password. I will provide a list of users and passwords as input to this program, see the format page for details. This program should also ensure that any of the support files required by the server are represented in the ACM. Note that this program is only used when re-initializing the server. If you server executed and told to restore a previously saved state this program will not be invoked (the C information is already stored, since it i was created and written by your program, so there should be no compatibility problems).