Understanding Labeled Networking in Linux

Another approachto further fine-tune access controls on the network level is to introduce labeled networking. With labeled networking, security information passes on between hosts (unlike SECMARK, which only starts when the netfilter subsystem receives the packet, and whose marking never leaves the host). This is also known as peer labeling, as the security information passes on between hosts (peers).

The advantage of labeled networking is that security information remains across the network, allowing end-to-end enforcement on mandatory access-control settings between systems as well as retaining the sensitivity level of communication flows between systems. The major downside, however, is that this requires an additional network technology (protocol) that can manage labels on network packets or flows.

SELinux currently supports two implementations as part of the labeled networking approach: NetLabel and labeled IPsec. With NetLabel, two implementations exist: fallback labeling and CIPSO. In both cases, only the sensitivity of the source domain is retained across the communication. Labeled IPsec supports transporting the entire security context with it.

Note:

NetLabel actually supports loopback-enabled, full-label support. In that case, the full label (and not only the sensitivity and categories) is passed on. However, this only works for communications that go through the loopback interface and, as such, do not leave the current host.

Quite some time ago, support for NetLabel/CIPSO and labeled IPsec merged into a common framework, which introduces three additional privilege checks in SELinux: interface checking, node checking, and peer checking. These privilege checks are only active when labeled traffic is used; without labeled traffic, these checks are simply ignored.

Fallback labeling with NetLabel

The NetLabel project supports fallback labeling, where administrators can assign labels to traffic fromor to network locations that don’t use labeled networking. By using fallback labeling, the peer controls mentioned in the next few sections can be applied even without labeled IPsec or NetLabel/CIPSO being in place.

Thenetlabelctlcommand controls the NetLabel configurations. Let’s create a fallback label assignment for all traffic originating from the192.168.100.1address:

# netlabelctl unlbl add interface:eth0 address:192.168.100.1 label:system_u:object_r:netlabel_peer_t:s0

To list the current definitions, use the following command:

# netlabelctl -p unlbl list
Accept unlabeled packets : on
Configured NetLabel address mappings (1)
 interface: eth0
   address: 192.168.100.1/32
    label: "system_u:object_r:netlabel_peer_t:s0"

With this rule in place, labeled networking is active. Any traffic originating from the192.168.100.1address will be labeled with thenetlabel_peer_t:s0label, while all other traffic will be labeled with the (default)unlabeled_t:s0label. Of course, the SELinux policy must allow all domains to have therecvpermission from either theunlabeled_tpeers or thenetlabel_peer_tpeers.

Fallback labeling is useful for supporting a mix of labeled networking environments and non-labeled networks, which is why we list it here before documenting the various labeled networking technologies.

Limiting flows based on the network interface

The ideainvolving interface checking is that each packet that comes into a system passes aningresscheck on an interface, whereas a packet that goes out of a system passes anegresscheck.ingressandegressare the SELinux permissions involved, whereas interfaces are given a security context.

Interface labels can be granted using thesemanagetool and are especially useful for assigning sensitivity levels to interfaces in case of MLS, although assigning different labels to the interface is also possible (but requires more adjustments to the running SELinux policy to return with a working system):

# semanage interface -a -t netif_t -r s1-s1:c0.c128 eth0

Like the other semanage commands, we can view the current mappings as follows:

# semanage interface -l
SELinux Interface	Context
eth0				system_u:object_r:netif_t:s1-s1:c0.c128

Keep in mind that for inbound communications, the acting domain is the peer. With labeled IPsec, this would be the client domain initiating the connection, whereas in NetLabel/CIPSO, this isthe associated peer label (such asnetlabel_peer_t).

By default, the interface is labeled withnetif_tand without sensitivity constraints. This will, however, not be shown in thesemanage interface -loutput as its default output is empty.

Accepting peer communication from selected hosts

SELinux nodes represent specific hosts (or a network of hosts) that data is sent to (sendto) or received from (recvfrom) and are handled through the SELinux node class. Just like interfaces, these can be listed and defined by the semanage tool. In the following example, we mark the 10.0.0.0/8 network with the node_t type and associate a set of categories with it:

# semanage node -a -t node_t -p ipv4 -M 255.255.255.255 -r s0-s0:c0.c128 192.168.100.1

Again, we can list the current definitions, too:

# semanage node -l

Like the network interface flow, the acting domain for incoming communications is the peer label.

By default, nodes are labeled withnode_tand without category constraints. This will, however, not be shown in thesemanage node -loutput as its default output is empty.

Verifying peer-to-peer flow

The final check is apeerclass check. For labeled IPsec, this isthe label of the socket sending out the data (such asmozilla_t). For NetLabel/CIPSO, however, the peer will be static, based on the source, as CIPSO is only able to pass on sensitivity levels. A common label seen for NetLabel isnetlabel_peer_t.

Unlike the interface and node checks, peer checks have the peer domain as the target rather than the source.

Note:

In all the labeled networking use cases, the process listed in a denial has nothing to do with the denial shown in the audit logs. This is because the denial triggers from within a kernel subsystem rather than through a call made by a user process. As a result, the kernel interrupts an unrelated process to prepare and log the denial, and this process name is used in the denial event.

To finish up, look at the following diagram, which provides an overview of these various controls and the level to which they apply:

The top-level controls are handled on the domain level (such as httpd_t), whereas the bottom-level controls are on the peer level (such as netlabel_peer_t).

Using old-style controls

Most Linuxdistributions enable thenetwork_peer_controlcapability. This is an enhancement within the SELinux subsystem that uses the previously mentioned peer class for verifying peer-to-peer flow.

However, SELinux policies can opt to return to the previous approach, where peer-to-peer flow is no longer controlled over the peer class, but uses thetcp_socketclass for communication. In that case, thetcp_socketclass will be used against thepeerdomain, and it will also use therecvfrompermission (on top of the existingtcp_socketpermissions).

The current value of thenetwork_peer_controlcapability can be queried through the SELinux filesystem:

# cat /sys/fs/selinux/policy_capabilities/network_peer_controls
1

If thevalue is0, then the previously mentioned peer controls will be handled through thetcp_socketclass instead of the peer class.

The defaultlabeled networking controls within SELinux do not pass on any process context, and the use of fallback labeling with NetLabel is most commonly used in environments where the system participates in both labeled as well as unlabeled networks. However, there is a much more common networking implementation that not only supports labeled networking, but even passes on the domain context and does not require specialized environments: labeled IPsec.