Due Date: Tu October 20, 2015 at 11:59pm.
In this assignment, you will complete a Linux Security Module that implements Low-Water Mark (LOMAC) integrity over file operations.
Follow these instructions:
Get the module code from here. This code contains two files: (1) sample.c, which contains an incomplete Linux Security Module that includes stubs for a set of authorization hooks (place in directory linux-2.6.23/security) and (2) Makefile, which enables sample.c to be compiled for the kernel (place in linux-2.6.23/security).
The first major task is to compile your Linux kernel (version 2.6.23) in your experimental environment, so that you can develop and test your sample LSM. Instructions for this task follow:
You will be assigned a VM for this purpose. Instructions for accessing the VM are here. I will send you information on your VM and its password(s) separately.
After logging into your VM, you must first configure and build a modified Linux kernel to run in the VM. For more information on kernel building see here. We do have a few modifications, so follow the remaining instructions to configure and build the kernel carefully.
To configure the kernel run make menuconfig. You need to change the configuration options slightly from the defaults. Under security options only select "Enable different security models" and "Socket and Networking Security Hooks" (as "built-in" or "*"). Save your kernel configuration. Verify that the file .config in the root source directory (should be linux-2.6.23) has been modified.
To build the kernel, we list the sequence of commands necessary to build the kernel from scratch and install all the components in the README.txt file in the root directory of your VM for your convenience. After you build the entire kernel, reboot your VM (see VM instructions).
If you make modifications to security/sample.c for your LSM (which you should), you will need to rebuild the module using the provided Makefile for security directory. Since you have already built the kernel, you can simply recompile the kernel (make -j32) and only the file sample.c will be compiled.
Run the module by loading using sudo insmod sample.ko. Unload the module with sudo rmmod sample. Check that the module is loaded via lsmod.
The goal of this project is to add code to the selected LSM authorization hooks (see the variable sample_ops in sample.c) as necessary to enforce Low-Water Mark (LOMAC) integrity (see the paper by Fraser assigned on 9/10/2015) over file operations. In general, the implementation must perform the following tasks:
First, ensure that the kernel objects that we authorize (processes and inodes) are assigned their correct labels. We label kernel objects based on the label assigned to the files used to create them. Using the filesystem's extended attributes, we store label strings "trusted" and "untrusted" in the file's security.sample attribute. Use the setfattr shell command to label files. See its man page.
The label of a process must be set in the function sample_bprm_set_security to the label of the file being executed. Helper functions are provided in sample.c to extract a file's label from its extended attributes. The label of an file inode being accessed (open, read, write) must be set before authorizing each operation. The label of a newly created file must be set in the function sample_inode_init_security.
Second, authorization decisions are made based on the labels of the process and inode and the operations requested by the process. For LOMAC, we define two label values (#defines in sample.c): SAMPLE_UNTRUSTED for low integrity and SAMPLE_TRUSTED for high integrity. Processes or inodes labeled SAMPLE_IGNORE need not be authorized. That is, authorization is only necessary when both the process and the inode are labeled either SAMPLE_TRUSTED or SAMPLE_UNTRUSTED.
Operations are defined in sample.c as well (#defines starting with MAY_). Operations have the expected semantics.
Students must modify the authorization decision function has_perm to enforce LOMAC semantics as defined in the Fraser paper for the specific labels and operations. Some of the authorization hooks use helper functions. The inode_has_perm function is a helper function that authorizes file and inode access.
Third, students must complete the code in the authorization hooks to enable enforcement of LOMAC policies. Students must determine whether a hook must either label a kernel object (e.g., a new file), change the label on an existing object (per LOMAC semantics), or request an authorization decision. A challenge of the assignment is to figure out what is necessary in which functions. To help understand this further, we list the mediation semantics of the LSM hooks below.
sample_inode_permission: mediates file open operations (on the file inode)
sample_bprm_set_security: mediates loading of a file into a process (e.g., on exec)
sample_inode_init_security: mediates initialization of a new inode object
sample_inode_setxattr: mediates modification of the extended attributes of a file's inode
sample_inode_create: mediates the return of a newly created file to the process
sample_file_permission: mediates operations on a file descriptor (read, write, append)
NOTE: Not all hooks may require additional code. Use the SELinux versions of the code (linux-2.6.23/security/selinux/hooks.c) for more information on what may be done.
I will assign some test programs to run in the future.
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.
NOTE: Currently, the sample LSM only logs authorization decisions, but does not actually block operations. An LSM authorization hook will block an operation if it returns any value other than 0. Be careful that you either return 0 or only block operations you intend to. Otherwise, other processes will stop working (you have the power, so be careful!).
Please submit your sample.c and your log of the run on the test programs.
When you have completed your module, submit it, the output, and the answers to the questions via ANGEL by 11:59pm on Fr September 25, 2015. Make sure that you have tested your submission prior to uploading.
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.