Home ›

Linux Distributed Security Module

Issue 102

From Issue #102
October 2002

Sep 30, 2002  By Miroslaw Zakrezewski and Ibrahim Haddad
 in
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 <
/usr/src/lsm-full-2002_01_15-2.4.17.patch
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.

______________________

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions