strongswan service file should be upstream one

Bug #1734886 reported by Vincent Bernat
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
strongswan (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Hello,

Ubuntu ships a custom /lib/systemd/system/strongswan.service. I have noticed if I start then stop strongswan without a delay, strongswan may end in a running state. There is a small race condition in how ipsec is started and the PID is written after forking while stop is using the PID to kill the running instance.

Upstream ships a far simpler systemd file:

[Service]
ExecStart=@SBINDIR@/@IPSEC_SCRIPT@ start --nofork
StandardOutput=syslog

Stop action is handled directly by systemd. No PID file handling is needed. However, since start is done with --nofork, the unit is ready while strongSwan may not be started yet. However, looking at the source code of strongSwan, I see it forks quite early, before charon is started. I would suggest to keep upstream service file (or patch it like Debian to add "reload" action).

CVE References

Revision history for this message
Joshua Powers (powersj) wrote :

Thanks for taking the time to file a bug! Can you specify what release of ubuntu you are running and what version of strongswan you are seeing this issue?

I took a look at the version in Debain unstable and Bionic and they looked similar.

Revision history for this message
Vincent Bernat (vbernat) wrote :

In Bionic, we have:

[Unit]
Description=strongSwan IPsec services
Wants=network-online.target
After=network-online.target

[Service]
Type=forking
Restart=on-failure
ExecStartPre=/bin/mkdir -p /var/lock/subsys
Environment="PIDFILE=/var/run/charon.pid"
ExecStart=/usr/sbin/ipsec start
ExecStop=/usr/sbin/ipsec stop
ExecStopPost=/bin/rm -f /var/run/charon.pid /var/run/starter.charon.pid

[Install]
WantedBy=multi-user.target

In unstable, we have:

[Unit]
Description=strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
After=network-online.target

[Service]
ExecStart=/usr/sbin/ipsec start --nofork
ExecReload=/usr/sbin/ipsec reload
StandardOutput=syslog
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

Debian only adds ExecReload= while Ubuntu ships a custom version.

Joshua Powers (powersj)
Changed in strongswan (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I already added that as part of the currently ongoing strongswan merge without knowing about the bug here.
We use the one Debian has (with the added reload) then.

This merge is prepared and currently in team review.
I added the bug to the changelog so that it will be pinged then when the package is released.

Changed in strongswan (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (8.9 KiB)

This bug was fixed in the package strongswan - 5.6.1-2ubuntu1

---------------
strongswan (5.6.1-2ubuntu1) bionic; urgency=medium

  * Merge with Debian unstable (LP: #1717343).
    Also fixes and issue with multiple psk's (LP: #1734207). Remaining changes:
    + Clean up d/strongswan-starter.postinst: section about runlevel changes
    + Clean up d/strongswan-starter.postinst: Removed entire section on
      opportunistic encryption disabling - this was never in strongSwan and
      won't be see upstream issue #2160.
    + Ubuntu is not using the debconf triggered private key generation
      - d/rules: Removed patching ipsec.conf on build (not using the
        debconf-managed config.)
      - d/ipsec.secrets.proto: Removed ipsec.secrets.inc reference (was
        used for debconf-managed include of private key).
    + Mass enablement of extra plugins and features to allow a user to use
      strongswan for a variety of extra use cases without having to rebuild.
      - d/control: Add required additional build-deps
      - d/control: Mention addtionally enabled plugins
      - d/rules: Enable features at configure stage
      - d/libbstrongswan-extra-plugins.install: Add plugins (so, lib, conf)
      - d/libstrongswan.install: Add plugins (so, conf)
    + d/strongswan-starter.install: Install pool feature, which is useful since
      we have attr-sql plugin enabled as well using it.
    + Add plugin kernel-libipsec to allow the use of strongswan in containers
      via this userspace implementation (please do note that this is still
      considered experimental by upstream).
      - d/libcharon-extra-plugins.install: Add kernel-libipsec components
      - d/control: List kernel-libipsec plugin at extra plugins description
      - d/p/dont-load-kernel-libipsec-plugin-by-default.patch: As
        upstream recommends to not load kernel-libipsec by default.
    + Relocate tnc plugin
     - debian/libcharon-extra-plugins.install: Drop tnc from extra plugins
     - Add new subpackage for TNC in d/strongswan-tnc-* and d/control
    + d/libstrongswan.install: Reorder conf and .so alphabetically
    + d/libstrongswan.install: Add kernel-netlink configuration files
    + Complete the disabling of libfast; This was partially accepted in Debian,
        it is no more packaging medcli and medsrv, but still builds and
        mentions it.
      - d/rules: Add --disable-fast to avoid build time and dependencies
      - d/control: Remove medcli, medsrv from package description
    + d/control: Mention mgf1 plugin which is in libstrongswan now
    + Add now built (since 5.5.1) libraries libtpmtss and nttfft to
      libstrongswan-extra-plugins (no deps from default plugins).
    + Add rm_conffile for /etc/init.d/ipsec (transition from precies had
      missed that, droppable after 18.04)
    + d/control, d/libcharon-{extras,standard}-plugins.install: Move charon
      plugins for the most common use cases from extra-plugins into a new
      standard-plugins package. This will allow those use cases without pulling
      in too much more plugins (a bit like the tnc package). Recommend that
      package from strongswan-libcharon.
  * Added changes:
    + d/s...

Read more...

Changed in strongswan (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.