Linux Distributed Security Module

Rebuilding the Kernel with LSM Options

The distributed security module is based on the LSM infrastructure, which is a set of hooks added to the kernel that installs the security patch from the LSM web site. The site contains many different patches; you need to match the patch with the appropriate kernel version, in our case kernel 2.4.17.

Follow these steps to patch the kernel with LSM. First, download lsm-full-2002_01_15-2.4.17.patch.gz into /usr/src. Then, unzip the patch:

% gunzip lsm-full-2002_01_15-2.4.17.patch.gz

Next go to the Linux source tree and apply the patch:

% cd /usr/src/linux % patch -p1 <
After applying the appropriate patch, reconfigure the kernel options to support the distributed security module. Modify the following options:
  • CODE MATURITY LEVEL: the prompt for development and/or incomplete code/drivers must be set to “y”.

  • LOADABLE MODULE SUPPORT: version information on all module symbols must be set to “n” to avoid problems with versioning.

  • NETWORKING OPTIONS: network packet filtering must be set to “y” to enable the net-filtering hooks for IP packet modification. Kernel httpd acceleration (EXPERIMENTAL) must be set to “m”. This option will include tcp_sync_mss in the kernel.

  • SECURITY OPTIONS: capabilities support should be set to “m”, IP networking support set to “n”, NSA SELinux Support set to “m”, NSA SELinux Development Module set to “y”, NSA SELinux MLS policy (EXPERIMENTAL) set to “n”, LSM port of Openwall (EXPERIMENTAL) set to “n” and Domain and Type Enforcement (EXPERIMENTAL) set to “n”.

Once you enable support for these options, simply build the kernel and modules, install them and run LILO normally.

Installing and Experimenting with DSM

Because all of the components of DSI are not currently implemented, we have created some test programs that emulate these parts, such as loading the security policy and alarm receivers. Before the module can be used it must be loaded into the kernel by root:

% /sbin/insmod lsm.o

Next, the policy must be supplied to the security module. For this exercise, the security file is a normal ASCII file with four fields: source security ID; target security ID; class (for now, only three classes are implemented: fork, socket and network); and permission.

An extract of the policy file goes like this:

1 1 1 0x01
1 1 2 0x07
1 1 3 0x01

The policy can be loaded with our test program, called UpdatePolicy:

% UpdatePolicy policy_file
The alarms can be received by our test program, CheckAlarm. The program is started using % CheckAlarm. The default label for a process can be overwritten by changing the first byte of the padding field in the ELF format of the process image (which is the eighth byte in the file).

Test Configuration

We performed three types of testing to develop a preliminary performance evaluation of the security module. The tests included process creation with fork, UDP local access and UDP remote access. The UDP tests were performed with and without IP packet modification, so as to see how much performance was lost during IP packet modification.

These tests were executed on a Pentium III 650MHz machine with 256MB of RAM. Here are our testing methods:

  1. Process Creation: measures the time required for a process to fork a child that immediately exits. The parent process loops 100,000 times, performing fork and wait calls.

  2. UDP Local Access: measures the time needed by a process to send a UDP message. It sends 500,000 UDP messages in a loop. The sending process does not check whether the message was sent outside the node, and it does not wait for the confirmation. In this case, it is not important whether the server has DSM installed or not.

  3. UDP Remote Access Testing: measures the time needed by a process to send a UDP message and receive a UDP response from a server. This test sends and receives 100,000 UDP messages in a loop. The client process will send a new message after receiving the confirmation from the server. In this case, it is important that the server runs the DSM software so that permissions are checked on the receiving side. For our test, the second server is a Pentium II 300MHz desktop with 128MB RAM.