Due Date: Th Feb 25, 2010 at 11:59pm.
In this assignment, you will complete a Linux Security Module for file access, develop a MAC policy for a program, and evaluate the program's security.
Follow these instructions:
Get the module code from here. This code contains three files: (1) sample.c, which contains a Linux Security Module that authorizes file access based on labels associated with files and executables (place in directory linux-188.8.131.52/security); (2) Makefile, which enables sample.c to be compiled for the kernel (place in linux-184.108.40.206/security); and (3) passwd.perms, which contains a few of the operations for labeling files using extended attributes (can be placed in your home directory).
In this project, we will focus on one user-space program, called the target program, which will be passwd. In this next project, you will get to examine a different program (your choice, with my approval). Here, we will determine the least privilege permissions for our target, and consider the operations that other programs may run that may impact our target's integrity.
Complete the functions has_perm, sample_inode_init_security, and sample_bprm_set_security in sample.c.
The has_perm function authorizes file and directory access based on a label (#defines starting with SAMPLE_) and a set of operations (#defines starting with MAY_). The semantics of the labels are as follows: (1) SAMPLE_READ_OBJ may be read by anyone; (2) SAMPLE_READ_WRITE may be read/written/appended by the target, but only read by others; (3) SAMPLE_WRITE_OBJ may be written/appended by the target, but not read, and only read by others; (4) SAMPLE_EXEC_OBJ may be read and executed by all; (5) SAMPLE_READ_DIR is for directories that may be read/exec accessed by all; (6) SAMPLE_RW_DIR are directories that may be modified by the target program, but not by others. SAMPLE_NO_ACCESS may not be accessed by target, but may be by others.
The sample_inode_init_security function enables labeling of files created by our target process. For example, a temporary file /etc/nshadow is created by passwd when a password is changed. Use the SELinux version of this function in linux-220.127.116.11/security/selinux/hooks.c as your guide. Note that you will have to add your function to sample_ops (like the others), and that this function returns -EOPNOTSUPP when no labeling is to be done.
The sample_bprm_set_security function labels a new process. In our case, a process is assigned an sid of SAMPLE_TARGET_SID if its security attribute is target. Otherwise, it runs under the sid 0. Use the setfattr shell command to label the file with target. This is the only entry in passwd.perms to start with.
Build the module by making the kernel. Since you have already built the kernel, only the file sample.c will be compiled. Run the module by loading using sudo insmod sample.ko. Then, run the passwd to change your password (keep careful track), and the run sudo vi /etc/shadow to edit the password file from a shell (don't need to make any mods -- just exit). Unload the module with sudo rmmod sample.
A log of the session will be captured in /var/log/messages. The statements identify the files that were authorized and not authorized by has_perm.
Take a look at the log to identify any files accessed by the passwd process that were not authorized (after you have built has_perm as specified). You must add the necessary permissions to passwd.perms to allow passwd to perform its tasks (evaluate the different options) without granting permission to vito edit /etc/shadow legally. The resultant log should reflect this case.
I have found it useful to prime passwd.perms with permissions based on tracing the program via strace. That may make your life easier.
NOTE: Your module should allow all operations (return 0 from sample_inode_permission), but simply log those that are denied. Otherwise, the system may stop working.
Please submit your sample.c, your log of the run of passwd and vi above, and your resultant passwd.perms file.
Also, please answer the questions below associated with the assignment. Include the answers in an ascii file.
When you have completed your module, submit it, the output, and the answers to the questions via ANGEL by 11:59pm on Th February 25. Make sure that you have tested your submission prior to uploading.
Does the least privilege policy that you built for passwd satisfy Biba integrity? Why or why not?
Does the least privilege policy that you built satisfy MLS security (assuming the password is more secret than everything else)? Why or why not?
Please classify the permissions accessed (for files only) based on initialization and passwd processing. Which files are necesary for passwd to be started, and how many are necessary for passwd to do its task? The easiest thing to do would be to distinguish these files in passwd.perms.
You are to complete this on your own. Any sharing of code or help during the coding of this project is expressly forbidden. Do not discuss this project with anyone.