** Description changed: [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. - * An explanation of the effects of the bug on users and + Furthermore, after any restart of that daemon, it will become confined, + which might be even more surprising to users. - * justification for backporting the fix to the stable release. + 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. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + 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://git.launchpad.net/ubuntu/+source/strongswan/commit/?h=ubuntu + /focal-devel&id=063994db81135f5f165c1913fcbd36e918163ab5 [Test Plan] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [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-recommends). Now, whenever strongswan-charon is installed with --no-install-recommends, strongswan-starter will not be included, which means the service will not be started. 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. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [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-standard-plugins (5.6.2-1ubuntu2.5) ... Setting up libcharon-standard-plugins (5.6.2-1ubuntu2.5) ... Setting up strongswan-libcharon (5.6.2-1ubuntu2.5) ... Setting up strongswan-starter (5.6.2-1ubuntu2.5) ... <============ Created symlink /etc/systemd/system/multi-user.target.wants/strongswan.service → /lib/systemd/system/strongswan.service. Setting up strongswan-charon (5.6.2-1ubuntu2.5) ... <============ Setting up strongswan (5.6.2-1ubuntu2.5) ... (...) $ ps axwZ|grep /usr/lib/ipsec/charon|grep -v grep unconfined 12374 ? Ssl 0:00 /usr/lib/ipsec/charon $ sudo aa-status | tail -n 2 1 processes are unconfined but have a profile defined. /usr/lib/ipsec/charon (12374) 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-libcharon (5.8.2-1ubuntu3.1) ... Setting up libcharon-extauth-plugins (5.8.2-1ubuntu3.1) ... Setting up strongswan-charon (5.8.2-1ubuntu3.1) ... <============ Setting up libstrongswan-standard-plugins (5.8.2-1ubuntu3.1) ... Setting up strongswan-starter (5.8.2-1ubuntu3.1) ... <============ Created symlink /etc/systemd/system/multi-user.target.wants/strongswan-starter.service → /lib/systemd/system/strongswan-starter.service. Setting up strongswan (5.8.2-1ubuntu3.1) ... (...) $ ps axwZ | grep /usr/lib/ipsec/charon | grep -v grep /usr/lib/ipsec/charon (enforce) 1720 ? Ssl 0:00 /usr/lib/ipsec/charon 1. https://launchpad.net/ubuntu/+source/strongswan/5.8.1-1ubuntu1
** Description changed: [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://git.launchpad.net/ubuntu/+source/strongswan/commit/?h=ubuntu /focal-devel&id=063994db81135f5f165c1913fcbd36e918163ab5 [Test Plan] - * detailed instructions how to reproduce the bug + In a bionic vm: + $ sudo apt install strongswan - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package fixes - the problem. + Verify that charon is running and confined: + $ ps axwZ | grep /usr/lib/ipsec/charon | grep -v grep + /usr/lib/ipsec/charon (enforce) 1720 ? Ssl 0:00 /usr/lib/ipsec/charon - * if other testing is appropriate to perform before landing this update, - this should also be described here. + In a system with the bug, the charon service is running unconfined: + $ ps axwZ|grep /usr/lib/ipsec/charon|grep -v grep + unconfined 12374 ? Ssl 0:00 /usr/lib/ipsec/charon + [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-recommends). Now, whenever strongswan-charon is installed with --no-install-recommends, strongswan-starter will not be included, which means the service will not be started. 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. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [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-standard-plugins (5.6.2-1ubuntu2.5) ... Setting up libcharon-standard-plugins (5.6.2-1ubuntu2.5) ... Setting up strongswan-libcharon (5.6.2-1ubuntu2.5) ... Setting up strongswan-starter (5.6.2-1ubuntu2.5) ... <============ Created symlink /etc/systemd/system/multi-user.target.wants/strongswan.service → /lib/systemd/system/strongswan.service. Setting up strongswan-charon (5.6.2-1ubuntu2.5) ... <============ Setting up strongswan (5.6.2-1ubuntu2.5) ... (...) $ ps axwZ|grep /usr/lib/ipsec/charon|grep -v grep unconfined 12374 ? Ssl 0:00 /usr/lib/ipsec/charon $ sudo aa-status | tail -n 2 1 processes are unconfined but have a profile defined. /usr/lib/ipsec/charon (12374) 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-libcharon (5.8.2-1ubuntu3.1) ... Setting up libcharon-extauth-plugins (5.8.2-1ubuntu3.1) ... Setting up strongswan-charon (5.8.2-1ubuntu3.1) ... <============ Setting up libstrongswan-standard-plugins (5.8.2-1ubuntu3.1) ... Setting up strongswan-starter (5.8.2-1ubuntu3.1) ... <============ Created symlink /etc/systemd/system/multi-user.target.wants/strongswan-starter.service → /lib/systemd/system/strongswan-starter.service. Setting up strongswan (5.8.2-1ubuntu3.1) ... (...) $ ps axwZ | grep /usr/lib/ipsec/charon | grep -v grep /usr/lib/ipsec/charon (enforce) 1720 ? Ssl 0:00 /usr/lib/ipsec/charon 1. https://launchpad.net/ubuntu/+source/strongswan/5.8.1-1ubuntu1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1932197 Title: charon apparmor profile not applied on fresh install To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1932197/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
