Although setting up and maintaining an IPsec setup is far beyond 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:
- The security policy database (SPD) contains the rules and information for the kernel to know when communication should be handled by an IP policy (and, as a result, handled through a security association).
- A security association (SA) is a one-way channel between two hosts and contains all 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.
- The security association database (SAD) contains the individual security associations.
Security associations 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 the
polmatchprivilege (part of the
associationclass) against this context. Also, domains that initiate an SA need to have the
setcontextprivilege (also part of the
associationclass) against the target domain.
- Only authorized domains can make modifications to the SPD, which is also governed through the
setcontextprivilege, but now also against the SPD context entries. This privilege is generally granted to IPsec tools, such as Libreswan’s pluto (
- Domains that participate in IPsec communication must have the
sendtoprivilege with their own association and the
recvfromprivilege with the association of the
peerdomain. The receiving domain also requires the
recvprivilege from the
peerclass associated with the
So while labeled IPsec cannot govern whether
mozilla_t can communicate with
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 is a matter of configuring Libreswan’s main configuration file (
ipsec.conf). Most distributions will use an
include directory (such as
/etc/ipsec.d) where admins or applications can place connection-specific settings. Generally, this
include directory is used for the actual IPsec configurations, whereas the general
ipsec.conf file is for Libreswan behavior.
To create a host-to-host connection, we first define a shared secret on both hosts. Let’s call the connection
rem1-rem2 (as those are the hostnames used for the two hosts), so the shared secret will be stored as
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:
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
# 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 use labeled IPsec with Libreswan, uncomment the
policy-label directives in the
/etc/ipsec.d/rem1-rem2.conf IPsec definition. Restart the
ipsec service, and try the connection again.
When an application tries to communicate over IPsec with remote domains,
pluto (or any other Internet 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 SAs and associate the same security 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.