Programming Assignment 4: Secure Password Programming Assigned: Tuesday, April 11, 2006 Due: Monday, May 8, Before 11:59 Pm
Total Page:16
File Type:pdf, Size:1020Kb
COMP150ICS Spring 2006 PA #4 (Programming Assignment) Programming Assignment 4: Secure Password Programming Assigned: Tuesday, April 11, 2006 Due: Monday, May 8, before 11:59 pm Often in shared projects, we want to allow limited access to various resources based on a username/password pair. In this assignment, you will use this type of authentication to allow read access to a file in your home directory. To help you write a secure program, we will provide you with a static analysis tool to look for security flaws in your program. You will be graded on both the functionality and security of your program. The things you should take away from this assignment are: (1) a better understanding of UNIX permission-based security, (2) an introduction to secure programming, and (3) some experience with a static vulnerability scanning tool. Requirements: For this project, you will write a secure setuid program that will allow others to access a file that is only readable by your UNIX account. • Your program should be named “lockbox”. • It should read a username and password from a user who runs the program. This username and password are separate from the UNIX passwords on the system. They are specific to your program. • If the username/password combination is valid, print the contents of an existing file named “lockbox.txt”. • Your program will also log the usernames of everyone who accessed “lockbox.txt” in another file named “lockbox.log”. • Rather than have a single username/password for file access, you will have separate usernames/passwords that can be issued to different possible users. • Provide a mechanism for adding and removing users who may access the file. This does not have to be fancy and can be part of your setuid program, or it can be some simple mechanism like hand-editing a configuration file. • If you use a configuration file, it should be named “lockbox.cfg”. • You do not need to use the setuid() system call to drop and add privileges. If you don’t know what that means, don’t worry about it. You should write your program in C on the moon Linux cluster. As always, you should also provide a Makefile. Testing your program: There are two parts to testing your program. First, you need to ensure that a different user can run the program, enter a valid username and password, and read your lockbox.txt file, but the same user cannot read the lockbox.txt file directly using less or emacs, for example. To do this, you will need to collaborate with your classmates. Provide a username and password and ask a classmate to test your program from his or her account. You may use the class discussion list to ask people to test your program. A caveat: You will need to put your program in the /tmp directory on either lin03 or lin04 for testing. You both need to agree which machine you are going to use, because, unlike your home directory, these are local to the machine. We suggest you make a directory under /tmp with your username and copy your files in there: % mkdir /tmp/eaftan % cp lockbox lockbox.cfg lockbox.txt /tmp/eaftan Once you put your program into /tmp, you can make it setuid. To make your program setuid: • Make sure it is world executable by doing chmod a+x lockbox • Make it setuid by doing chmod u+s lockbox See the chmod man page for more information. You will also need to set the correct permissions for your directory in /tmp and also the lockbox.cfg and lockbox.txt files. Part of this assignment is figuring out what these permissions should be. When done testing, we recommend that you unset the setuid bit by doing chmod u-s lockbox. This is more secure for the files in your account. Do not store your files in /tmp! Your files are not guaranteed to stick around for any amount of time. Do all your work in your home directory, and then copy it to /tmp, fix the permissions, and enable the setuid bit. The second part of testing your program involves checking for security flaws. One way to do this is obvious: try to break it. Pass in bad input, do strange things to the files it uses, etc. Another way is to use a source code scanner to look for security flaws. We have provided a tool called its4 (It’s the Software, Stupid! Security Scanner) for you to use. It is included in the pa4.tar.gz file on the course website. You can run it by typing “its4 lockbox.c”, and it will try to find common errors in your program. If you’re interested, there is a paper on its4 here: http://www.cigital.com/papers/download/its4.pdf Background: There are a few UNIX concepts you will need to understand to do this assignment. Permissions On a shared UNIX system, file system permissions allow you to specify who can access which files, and what modes (read, write, execute) they can access them in. Every file is owned by a certain user and group and is given a set of permissions. You can use the “ls -l” command to see the owner, group, and permissions of all files in a directory: % ls -l total 12 -rwxr-xr-x 1 eaftan dip 5013 Apr 10 11:42 tester -rw-rw-r-- 1 eaftan dip 216 Apr 10 11:38 tester.c -rw-rw-r-- 1 eaftan dip 15 Apr 10 11:38 testfile.txt Let’s examine this output. The first column of each line is the permissions for that file. The first letter is whether the entry is a directory. After that, each group of three letters represents the permissions bits for the owner, group, and others. There are three possible bits you can set for each type of users: “r” for read, “w” for write, and “x” for execute. So for testfile.txt, both the owner and group have read and write permissions, but others can only read the file. For the tester file, the owner had read, write, and execute permissions, Directories work slightly differently. To be able to enter a directory, you need execute permissions. To be able to see a directory listing, you need read permissions on the directory. Look at the example below lin03{eaftan}64: ls -l total 92 drwxr-x--x 2 eaftan dip 4096 Apr 11 12:13 eaftan The eaftan directory has read, write, and execute set for the owner, so the owner can do whatever he wants to the directory. For group, it has read and execute set, so a group member can enter the directory and also list its contents. For other, it has only the execute bit set, so others will only be able to enter the directory but not list its contents. You use chmod to change the permissions for a file. Chmod can be pretty complicated. Use “man chmod” to find out more about this program, or refer to this web page: http://www.zzee.com/solutions/chmod-help.shtml If you are still confused, don’t worry. UNIX permissions are complicated. Here is another resource that might help: http://www.zzee.com/solutions/unix-permissions.shtml setuid One of the permissions bits allows you to turn on setuid for a program. setuid allows the program to be executed by another user as the owner of the file. So for example, suppose I have a program called “password” in my home directory, it is owned by me, and the setuid bit is on. If you execute this file, it will run as me and be able to do anything I can do. It can read files that are meant to be readable only by me. This is very dangerous as the setuid program can do anything I could do. It can read my files, delete them, etc. Thus you have to be very aware of security when writing a setuid program. You can turn on setuid for a program by using chmod as follows: % chmod u+s [file] Questions: Please provide the answer to the following questions in a plain-text file named “answers.txt” included with your submission: 1) What should the permissions be for the binary, config file, text file, and directory in /tmp for someone else to be able to test your program? 2) Did the its4 tool emit any warnings that weren’t a true security risk? How did you know that this warning didn’t apply to your program? Grading: You will be graded based on functionality and security. If your program works perfectly, you will receive 45 points. Another 45 points come from the security of your program. We will be looking for things like: • Possible buffer overflows • Hashing the passwords in your password file (crypt without salt is sufficient for full credit) • Incomplete mediation • TOCTOU (race conditions) • Using dangerous C functions • Etc. The final 10 points come from your answers to the questions. Turning in your assignment: The assignment must be turned in electronically on the departmental Linux machines (moon.eecs.tufts.edu). You should create one tarred and gzipped file named “lockbox.tar.gz” containing the answers to the questions, your source code, a makefile for building, your .cfg and .txt files that your program uses, and a README that explains how to use your program and how to add/delete usernames and passwords. To create the tarball, use this command: % tar czvf lockbox.tar.gz answers.txt Makefile lockbox.c <...> Where the “…” is all the other files you want to submit.