Security Distribution for Linux Clusters

Here are the kernel mechanisms used in DSM to embed security information into IP messages in a transparent way.
Adding Network Security Hooks

The security module can influence the routing decision based on the security hook implementation. A few things need to be remembered when programming the routing hooks, because those hooks are executed as normal kernel functions for every packet coming in and out the kernel.

A module that registers a function must specify the priority of the function within the hook. The net filter hooks are called from the kernel code in the order of priorities. The user functions are free to manipulate the IP packet. The user function must return one of the following values in order for the networking code to decide what to do with the packet:

  1. NF_ACCEPT: do nothing and let the packet go through the network stack.

  2. NF_DROP: drop the packet. The packet is not passed for further processing.

  3. NF_STOLEN: the packet has been taken. The packet is not passed for further processing.

  4. NF_QUEUE: queue the packet for user-space handling.

  5. NF_REPEAT: call this hook again.

This function shows us how the packet is manipulated before it enters the system and before it is sent out. What we are still missing is: what kind of information or options can we add to the packet? How? And, will the changes coexist with the current implementation? We answer these questions in the following sections.

IP Options

A little-known fact about Internet Protocol is that an IP packet can contain a variable amount of extra information (maximum of 40 bytes) following the standard 20-byte header. These extension bytes are called IP options, and some of the options are defined to carry security information.

Currently, the Internet Protocol includes two security options. One of them is the DoD Basic Security Option (BSO—Option Type 130), which allows IP datagrams to be labeled with security classifications. This option provides 16 security classifications and a variable number of handling restrictions. To handle additional security information, such as security categories or compartments, a second security option (ESO—Option Type 133) exists and is referred to as the DoD Extended Security Option (ESO). The Defense Information Systems Agency (DISA) is responsible for administrating the values for the fixed fields within these two options.

Computer vendors now are building commercial operating systems with mandatory access controls and multilevel security. These systems are no longer built specifically for a particular group in the defense or intelligence communities. They are generally available commercial systems for use in a variety of government and civil sector environments.

The small number of ESO format codes cannot support all the possible applications of a commercial security option. The BSO and ESO were designed to support only the United States DoD. Commercial IP Security Option (CIPSO) has been designed to support multiple security policies. The Internet draft provides the format and procedures required to support a mandatory access control (MAC) security policy.

The IP options used to label packets in our implementation are based on the FIPS 188 standard and the Commercial IP Security Option (CIPSO) draft. In our implementation, the IP header is changed using these standards, so we can add the security information to the IP header and send it over the network.

IP Options in DSM

The security information we want to transfer using IP options are Security ID (SID) and Security Node ID (NID). The DSM modifies every IP packet by supplying our security information as its IP options. Figure 2 shows the format of the modified IP header.

Figure 2. Security Options in the IP Header

Here is a list of header options:

  • CIPSO: one octet, with a value of 134.

  • Length: one octet, the total length of the option including the type and length fields. With the current IP header length restriction of 40 octets, the value of this field must not exceed 40.

  • Domain of Interpretation (DOI) Identifier: unsigned 32-bit integer. The value 0 is reserved and must not appear as the DOI identifier in any CIPSO option. Implementations should assume the DOI identifier field is not aligned on any particular byte boundary.

  • The CIPSO Domain of Interpretation (DOI) Field, or the Security Tag Set Name under FIPS 188: set to hexadecimal 10001000. This DOI value was selected arbitrarily as there currently is no relevant regulatory activity in this area.

  • Free Form: one octet, indicates that the following fields are new fields undefined in the standard (therefore free). The value is 7.

  • Length: one octet, indicates the total length of all tags.

  • Tags (SID, NID): CIPSO uses sets of tags to contain the security information relevant to the data in the IP packet. Each tag begins with a tag type identifier followed by the length of the tag; it ends with the actual security information to be passed.

  • SID tag: tag id: one octet (value 3), tag length: one octet (value 6), tag data: 32-bit value of sid.

  • NID tag: tag id: one octet (value 6), tag length: one octet (value 6), tag data: 32-bit value of nid.

  • The IP option we use is CIPSO. Those fields are not defined by the standard, so they can be used in the way we define.

  • The Domain of Interpretation (DOI) and the Free Form (FIPS 188 standard) mean that the following fields are new fields undefined in standard, therefore they are free.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix