Using labeled IPsec with SELinux

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 polmatch privilege (part of the association class) against this context. Also, domains that initiate an SA need to have the setcontext privilege (also part of the association class) against the target domain.
  • Only authorized domains can make modifications to the SPD, which is also governed through the setcontext privilege, 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 the sendto privilege with their own association and the recvfrom privilege with the association of the peer domain. The receiving domain also requires the recv privilege from the peer class associated with the peer domain.

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:

labeled ipsec

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 /etc/ipsec.d/rem1-rem2.secrets: : PSK "somesharedkey"

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


conn rem1-rem2

The settings that 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 use labeled IPsec with Libreswan, uncomment the labeled-ipsec and 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.

Related Articles

No Results Found

The page you requested could not be found. Try refining your search, or use the navigation above to locate the post.

Lorem ipsum dolor sit amet consectetur


Submit a Comment

Your email address will not be published. Required fields are marked *

ten + 17 =