Supporting CIPSO with NetLabel and SELinux

NetLabel/CIPSOlabels and transmits sensitivities across thenetwork. Unlike labeled IPsec, no other contextinformation is sent or synchronized. So, whenwe consider the communication flows between two points, they will have a default, common SELinux type (rather than the SELinux type associated with the source or target) but will have sensitivity labels based on the sensitivity label of the remote side.

Part of NetLabel’s configuration are mapping definitions that inform the system which communication flows (from selected interfaces, or even from configured IP addresses) are for a certainDomain of Interpretation(DOI). The CIPSO standard defines the DOI as a collectionof systems that interpret the CIPSO label similarly, or, in our case, use the same SELinux policy and configuration of sensitivity labels.

Once these mappings have been established, NetLabel/CIPSO will pass on the sensitivity information (and categories) between hosts. The context we will see on the communication flows will benetlabel_peer_t, a default context assigned to NetLabel/CIPSO-originated traffic.

Through this approach, we can start daemons with a sensitivity range and thus only accept connections from users or clients that have the right security clearance, even on remote, NetLabel/CIPSO-enabled systems.

Configuring CIPSO mappings

A preliminaryrequirement for having a good CIPSO-enabled network is to have a common understanding of which DOI will be used and what its consequences are. Labeled networks can use different DOIs for specific purposes.

Along with the DOI, we also need to take care of how the categories and sensitivities are passed on over the CIPSO-enabled network. The CIPSO tag controls this setting, and NetLabel supports this with the following three values:

• Withtags:1, the categories are provided in the CIPSO package in a bitmap approach. This is the most common approach, but limits the number of supported categories to 240 (from 0 to 239).
• Withtags:2, the categories are enumerated separately. This allows a wider range of categories (up to 65,543), but only supports at most 15 enumerated categories. Try to usetags:2when you have many categories but for each scope, only a few categories need to be supported.
• Withtags:5, the categories can be mentioned in a ranged approach (lowest and highest), with at most seven such low/high pairs.

Note that the CIPSO tag results are handled under the hood: system administrators only need to configure the NetLabel mapping to use a selected tag value.

Let’s assume that we have two CIPSO-enabled networks, which have10.1.0.0/16associated withdoi:1and10.2.0.0/16associated withdoi:2. Both use the tag value1. First, we enable CIPSO and allow it to pass CIPSO-labeled packages with the DOI set to either1or2. We don’t perform any translations (so the category and sensitivity set on the CIPSO package is the one used by SELinux):

# netlabelctl cipsov4 add pass doi:1 tags:1
# netlabelctl cipsov4 add pass doi:2 tags:1

If we need to translate (say that we use sensitivity s0-s3 while the CIPSO network uses sensitivity 100-103), a command would look like so:

# netlabelctl cipsov4 add std doi:1 tags:1 
levels:0=100,1=101,2=102

Next, we implement mapping rules, telling the NetLabel configuration which network traffic is to be associated with doi:1 or doi:2:

# netlabelctl map del default
# netlabelctl map add default address:10.1.0.0/16 protocol:cipsov4,1
# netlabelctl map add default address:10.2.0.0/16 protocol:cipsov4,2

To list the current mappings, use the list option:

# netlabelctl map list -p
Configured NetLabel domain mappings (2)
 domain: DEFAULT (IPv4)
   address: 10.1.0.0/16
    protocol: CIPSO, DOI = 1
 domain: DEFAULT (IPv4)
   address: 10.2.0.0/16
    protocol: CIPSO, DOI = 2

That’s it. We removed the initial default mapping (as that would prevent the addition of new default mappings) and then configured NetLabel to tag traffic for the given networks with the right CIPSO configuration.

Adding domain-specific mappings

NetLabel can also be configured to ensure that given SELinux domains use a well-defined DOI rather than the default one configured earlier on. For instance, to have the SSH daemon (running in the sshd_t domain) have its network traffic labeled with CIPSO doi:3, we’d use this:

# netlabelctl cipsov4 add pass doi:3 tags:1
# netlabelctl map add domain:sshd_t protocol:cipsov4,3

The mapping rules can even be more selective than that. We can tell NetLabel to use doi:2 for SSH traffic originating from one network, use doi:3 for SSH traffic originating from another network, and even use unlabeled network traffic when it comes from any other network:

# netlabelctl map del domain:sshd_t protocol:cipsov4,3
# netlabelctl map add domain:sshd_t address:10.1.0.0/16 protocol:cipsov4,1
# netlabelctl map add domain:sshd_t address:10.4.0.0/16 protocol:cipsov4,3
# netlabelctl map add domain:sshd_t address:0.0.0.0/0 protocol:unlbl

The NetLabel framework will try to match the most specific rule first, so 0.0.0.0/0 is only matched when no other rule matches.

Using local CIPSO definitions

As mentioned before, NetLabel, by default, only passes the sensitivity and categories. However, whenusing local (over the loopback interface) CIPSO, it is possible to use full label controls. When enabled, peer controls will not be applied against the defaultnetlabel_peer_ttype, but will use the client or server domain.

To use local CIPSO definitions, first declare the DOI for local use:

# netlabelctl cipsov4 add local doi:5

Next, have the local communication use the defined DOI (5 in our example):

# netlabelctl map add default address:127.0.0.1 protocol:cipsov4,5

With this enabled, local communication will be associated with doi:5 and use the local mapping, passing the full label to the mandatory access control system (SELinux).

Supporting IPv6 CALIPSO

CIPSO isan IPv4 protocol, but a similar framework exists for IPv6, namedCommon Architecture Label IPv6 Security Option(CALIPSO). As with CIPSO, CALIPSOis supported by the NetLabel project. When we need CALIPSO support, the protocol target iscalipsorather thancipsov4.

CALIPSO has a few small differences compared to CIPSO in NetLabel:

• Only one tag type is supported (unlike CIPSO’s three tag types). As a result, CALIPSO administrators do not need to specifytags:#anywhere.
• CALIPSO only uses pass-through mode. Translations are not supported.
• The NetLabel CALIPSO implementation currently does not support local mode, where the full label would be passed on.

Beyond these differences, the use of CALIPSO is very similar to CIPSO.