Security Distribution for Linux Clusters
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:
NF_ACCEPT: do nothing and let the packet go through the network stack.
NF_DROP: drop the packet. The packet is not passed for further processing.
NF_STOLEN: the packet has been taken. The packet is not passed for further processing.
NF_QUEUE: queue the packet for user-space handling.
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.
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.
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.
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.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development