Using Labeled IPsec with SELinux

Althoughsetting up and maintaining an IPsec setup is farbeyond the scope of this book, let’s look at a simple IPsec example to show how to enable labeled IPsec on a system. Remember that the labeled network controls on the interface, node, and peer levels, as mentioned earlier, are automatically enabled the moment we use labeled IPsec.

In an IPsec setup, there are three important concepts to be aware of:

• Thesecurity policy database(SPD) contains the rules and information for the kernelto know when communication should be handled by an IP policy (and, as a result, handled through a security association).
• Asecurity association(SA) is a one-way channel between two hosts and containsall the security information about the channel. When labeled IPsec is in use, it also contains the context information of the client that caused the security association to materialize.
• Thesecurity association database(SAD) contains the individual security associations.

Securityassociations with a labeled IPsec setup are no longer purely indexed by the source and target address, but also the source context. As such, a Linux system that participates in a labeled IPsec setup will easily have several dozen SAs for a single communication flow between hosts, as each SA now also represents a client domain.

Labeled IPsec introduces a few additional access controls through SELinux:

• Individual entries in the SPD are given a context. Domains that want to obtain an SA need to have thepolmatchprivilege (part of theassociationclass) against this context. Also, domains that initiate an SA need to have thesetcontextprivilege (also part of theassociationclass) against the target domain.
• Only authorized domains can make modifications to the SPD, which is also governed through thesetcontextprivilege, but now also against the SPD context entries. This privilege is generally granted to IPsec tools, such as Libreswan’s pluto (ipsec_t).
• Domains that participate in IPsec communication must have thesendtoprivilege with their own association and therecvfromprivilege with the association of thepeerdomain. The receiving domain also requires therecvprivilege from thepeerclass associated with thepeerdomain.

So while labeled IPsec cannot govern whether mozilla_t can communicate with httpd_t (as mozilla_t only needs to be able to send to its own association), it can control whether httpd_t allows or denies incoming communication from mozilla_t (as it requires the recvfrom privilege on the mozilla_t association). The following diagram displays this complex game of privileges:

In the next example, we will set up a simple IPsec tunnel between two hosts using the Libreswan tool.

Setting up regular IPsec

Configuring Libreswan isa matter of configuring Libreswan’s main configuration file (ipsec.conf). Most distributions will use anincludedirectory (such as/etc/ipsec.d) where admins or applications can place connection-specific settings. Generally, thisincludedirectory is used for the actual IPsec configurations, whereas the generalipsec.conffile is for Libreswan behavior.

To create a host-to-host connection, we first define a shared secret on both hosts. Let’s call the connectionrem1-rem2(as those are the hostnames used for the two hosts), so the shared secret will be stored as/etc/ipsec.d/rem1-rem2.secrets:

192.168.100.4 192.168.100.5 : PSK "somesharedkey"

Next, we define the VPN connection in /etc/ipsec.d/rem1-rem2.conf as follows:

rem1-rem2.conf

conn rem1-rem2
	left=192.168.100.4
	right=192.168.100.5
	auto=start
	authby=secret
	#labeled-ipsec=yes
	#policy-label=system_u:object_r:ipsec_spd_t:s0

The settingsthat enable labeled IPsec are commented out for now to first test the IPsec connection without this feature.

Launch the IPsec service on both systems:

# systemctl start ipsec

Verify whether the connection works, for instance, by checking the network traffic with tcpdump, or by checking the state with ip xfrm state

Enabling labeled IPsec

To uselabeled IPsec with Libreswan, uncomment thelabeled-ipsecandpolicy-labeldirectives in the/etc/ipsec.d/rem1-rem2.confIPsec definition. Restart theipsecservice, and try the connection again.

Whenan application tries to communicate over IPsec with remote domains,pluto(or any otherInternet Key Exchange version 2(IKEv2) client that supports labeled IPsec) will exchange the necessary information (including context) with the other side. Both sides will then update the SPD with the necessary SAsand associate the samesecurity policy information(SPI) with it. From that point onward, the sending side will add the agreed-upon SPI information to the IPsec packets so that the remote side can immediately associate the right context with it again.

The huge advantage here is that the client and server contexts, including sensitivity and categories, are synchronized (they are not actually sent over the wire with each packet, but exchanged initially when the security associations are set up).

In certain specialized or highly secure environments, labeled networking is supported within the network itself. The most common labeling technology used is CIPSO, whose SELinux support we cover next.