NetLabel/CIPSO labels and transmits sensitivities across the network. Unlike labeled IPsec, no other context information is sent or synchronized. So, when we 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 certain Domain of Interpretation (DOI). The CIPSO standard defines the DOI as a collection of 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 be
netlabel_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 preliminary requirement 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:
tags: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).
tags: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 use
tags:2when you have many categories but for each scope, only a few categories need to be supported.
tags: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 have
10.1.0.0/16 associated with
10.2.0.0/16 associated with
doi:2. Both use the tag value
1. First, we enable CIPSO and allow it to pass CIPSO-labeled packages with the DOI set to either
2. 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
# 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
# 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
# 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
Adding domain-specific mappings
# 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, when using local (over the loopback interface) CIPSO, it is possible to use full label controls. When enabled, peer controls will not be applied against the default
netlabel_peer_t type, 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 is an IPv4 protocol, but a similar framework exists for IPv6, named Common Architecture Label IPv6 Security Option (CALIPSO). As with CIPSO, CALIPSO is supported by the NetLabel project. When we need CALIPSO support, the protocol target is
calipso rather than
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 specify
- 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.