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 the
polmatch
privilege (part of theassociation
class) against this context. Also, domains that initiate an SA need to have thesetcontext
privilege (also part of theassociation
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 therecvfrom
privilege with the association of thepeer
domain. The receiving domain also requires therecv
privilege from thepeer
class associated with thepeer
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:
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 aninclude
directory (such as/etc/ipsec.d
) where admins or applications can place connection-specific settings. Generally, thisinclude
directory is used for the actual IPsec configurations, whereas the generalipsec.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 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-ipsec
andpolicy-label
directives in the/etc/ipsec.d/rem1-rem2.conf
IPsec definition. Restart theipsec
service, 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.