Due Date: Fr March 4, 2011 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-22.214.171.124/security); (2) Makefile, which enables sample.c to be compiled for the kernel (place in linux-126.96.36.199/security); and (3) cp.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 the fileutil cp. The aim is to configure a sandbox for the cp program that allows authorized copying, but prevents some forms of malicious copying. When copying a file, the following requirements must be met.
The copying process must be authorized to create a new file in the target directory.
The copying process must be able to write to the file if a file already is present under that filename (if it has permission to write to that file).
The copying process should only follow a link if the link is authorized for the process.
Complete the functions dentry_has_perm, sample_inode_follow_link, and sample_inode_create in sample.c.
The dentry_has_perm function is a helper function that authorizes file and directory access. In general, it should extract the inode for the dentry and call inode_has_perm, which calls has_perm to perform the actual authorization. A version of these two latter functions is provided for you.
Authorization is 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. (7) SAMPLE_LINK is a new label that identifies a link that may be traversed by the target (and others). SAMPLE_NO_ACCESS may not be accessed by target, but may be by others.
The sample_inode_follow_link is a function that authorizes traversal of a link. When cp is called it may only follow a link if the link is authorized. This is denoted by the extended attribute security.sample of the file being set to "link". At runtime, has_perm will authorize the process if the file has the SAMPLE_LINK label and the operation is MAY_LINK. Thus, you must write sample_inode_follow_link to authorize the target process only when the authorized links above are followed. Other processes should always be authorized. Use the SELinux version of this function in linux-188.8.131.52/security/selinux/hooks.c as your guide.
The sample_inode_create function authorizes the creation of a new file and labels that file. 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 cp.perms to start with.
Build the module by making the kernel with security/sample.c using the provided Makefile for security directory. 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 copying cases described below. Unload the module with sudo rmmod sample.
Perform the following operations: (1) create a file input that your cp process can "read-only"; (2) use cp to copy that file into another directory, which should only be authorized if cp.perms grants "read-write" access to the directory; (3) create a link badlink to a file /boot/important, to which cp does not have access to follow; (4) copy input to badlink, which should not be authorized; and (5) create a link goodlink to a file /etc/important, to which cp has authorization to follow, "link" permission; and (6) copy input to goodlink, which should work.
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 cp process that were not authorized (after you have built has_perm as specified). You must add the necessary permissions to cp.perms to allow cp to perform its tasks (evaluate the different options). The resultant log should reflect this case.
I have found it useful to prime cp.perms with permissions based on tracing the program via strace. That may make your life easier.
NOTE: Your module must block operations for the target process only. Otherwise, other processes will stop working (you have the power, so be careful!).
Please submit your sample.c, your log of the run of cp and vi above, and your resultant cp.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 Fr March 4. Make sure that you have tested your submission prior to uploading.
Suppose you wrote a setuid program (script) performed sandboxed copying by allowing the caller to set permissions (establish the sandbox) and perform the copy. What would be some problems with that approach?
Suppose you wanted to design an LSM to control copying for all processes based on this approach. Is it possible? If so, how would it work?
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.