charon apparmor profile not applied on fresh install
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
strongswan (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Andreas Hasenack |
Bug Description
[Impact]
A fresh install of strongswan that include the strongswan-charon package will have the charon daemon running unconfined, despite there being an apparmor profile for it by default.
Furthermore, after any restart of that daemon, it will become confined, which might be even more surprising to users.
This happens because strongswan-starter is configured before strongswan-charon. Since -starter starts the charon service (the -charon package is unpacked by then), but only -charon loads the apparmor profile into the kernel, the charon daemon starts unconfined. But any restart afterwards will pick up the apparmor profile.
The fix for this was a change in the dependencies between strongswan-starter (the package that ships the systemd service file) and strongswan-charon, which ships the daemon and its apparmor profile. This change is already applied in focal and later, and was cherry-picked as-is: https:/
[Test Plan]
In a bionic vm:
$ sudo apt install strongswan
Verify that charon is running and confined:
$ ps axwZ | grep /usr/lib/
/usr/lib/
In a system with the bug, the charon service is running unconfined:
$ ps axwZ|grep /usr/lib/
unconfined 12374 ? Ssl 0:00 /usr/lib/
[Where problems could occur]
1) The fix introduces a slight change in behavior if the user has disabled the installation of Recommended packages (i.e., apt install <pkg> --no-install-
2) Because of the bug, fresh installs of the charon daemon will have it running unconfined, possibly without the user noticing. After any restart, though, it will become confined, so I don't think we will have many such cases out there in the wild. That being said, if there is a config that is incompatible with the apparmor profile, and that wasn't noticed before, now it can affect the service, since charon will, correctly, start in confined mode.
3) Restarting strongswan unattended, like how it happens during an automatic update, is not always a good idea, as it could disrupt traffic severely and leave a system unreachable. I believe sites that are sensitive to this will already have taken precautions, though.
[Other Info]
This fix represents a delta we have with Debian since it was first applied to focal. Christian and others spent a great amount of effort in trying to push this (and other bits of our delta) to debian:
- starting with https:/
- https:/
- https:/
- https:/
- https:/
And others.
[Original Description]
Due to ordering of package installations, the apparmor profile for the `charon` daemon is not applied to the service on a fresh install on bionic.
For `apt install strongswan`, we get:
(...)
Setting up libstrongswan (5.6.2-1ubuntu2.5) ...
Setting up libstrongswan-
Setting up libcharon-
Setting up strongswan-
Setting up strongswan-starter (5.6.2-1ubuntu2.5) ... <============
Created symlink /etc/systemd/
Setting up strongswan-charon (5.6.2-1ubuntu2.5) ... <============
Setting up strongswan (5.6.2-1ubuntu2.5) ...
(...)
$ ps axwZ|grep /usr/lib/
unconfined 12374 ? Ssl 0:00 /usr/lib/
$ sudo aa-status | tail -n 2
1 processes are unconfined but have a profile defined.
/usr/
See how strongswan-starter is setup before strongswan-charon. What happens is that -starter starts the services (including charon), but the apparmor profile is only loaded into the kernel by the strongswan-charon's postinst package, therefore too late.
In focal and later, the dependencies were changed[1]:
strongswan-starter: replaced "Recommends: strongswan-charon" with "Depends: strongswan-charon"
strongswan-charon: replaced "Depends: strongswan-starter" with "Recommends: strongswan-starter"
This has the effect that strongswan-charon will be configured already (i.e., the apparmor profile will be loaded into the kernel) by the time strongswan-starter comes along and (re)starts the services:
(...)
Setting up libstrongswan (5.8.2-1ubuntu3.1) ...
Setting up strongswan-
Setting up libcharon-
Setting up strongswan-charon (5.8.2-1ubuntu3.1) ... <============
Setting up libstrongswan-
Setting up strongswan-starter (5.8.2-1ubuntu3.1) ... <============
Created symlink /etc/systemd/
Setting up strongswan (5.8.2-1ubuntu3.1) ...
(...)
$ ps axwZ | grep /usr/lib/
/usr/lib/
1. https:/
Related branches
- Lucas Kanashiro (community): Approve
- Canonical Server Core Reviewers: Pending requested
-
Diff: 42 lines (+10/-2)2 files modifieddebian/changelog (+8/-0)
debian/control (+2/-2)
Changed in strongswan (Ubuntu): | |
status: | New → Fix Released |
Changed in strongswan (Ubuntu Bionic): | |
assignee: | nobody → Andreas Hasenack (ahasenack) |
importance: | Undecided → High |
Changed in strongswan (Ubuntu): | |
importance: | Undecided → High |
Changed in strongswan (Ubuntu Bionic): | |
status: | Confirmed → In Progress |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Status changed to 'Confirmed' because the bug affects multiple users.