Running strongSwan with reduced privileges

For most setups, strongSwan can run with reduced privileges. Dropping Linux capabilities limits the process to networking operations and prevents an attacker from doing evil things, such as installing rootkits.
Changing user and group to non-root protects files on the system.

Dropping capabilities

strongSwan supports capability dropping. The IKE daemon is started as root and most of it's privileges are dropped immediately. After the daemon has been initialized, further unneeded capabilities are dropped.

To enable capability dropping, you'll need the libcap library and configure strongSwan with

--with-capabilities=libcap

Depending on the loaded plugins the daemon keeps some capabilities (e.g. CAP_NET_ADMIN or CAP_NET_RAW) to communicate with the kernel's IPsec subsystem or to use RAW sockets. Therefore, a potential attacker is still able to fetch and change network configuration options, but it is unable to do greater harm to the system (such as installing root kits).

Running strongSwan as non-root

strongSwan allows to run its daemon under a non-root user.

Running the IKE daemon as non-root user breaks support for iptables updown script.

iptables is unable to handle capabilities and does not allow non-root users to insert rules, even if that user has the required capabilities. If you use a non-root user, the leftfirewall parameter won't work unless you customize the updown script to use sudo for calls to iptables. Using a non-root group does not affect the updown script support.

To use a non-root user, you'll need to create a new user and group for strongSwan, e.g.:

groupadd vpn
useradd -g vpn vpn

The ./configure options

--with-user=vpn --with-group=vpn

build the IKE daemon with non-root user support.

make install will install configuration files with this user/group, but double check existing configuration file permissions.

Since 5.1.0 it is also possible to change the user and group later using the charon.user and charon.group strongswan.conf options, respectively. File permissions may have to be adjusted, otherwise, the daemon might not be able to access e.g. ipsec.secrets or /etc/ipsec.d/private.