** 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] In a bionic vm: $ sudo apt install strongswan 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 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] + 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://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848890, which lead to the MRs below: + - https://salsa.debian.org/debian/strongswan/merge_requests/8 + - https://salsa.debian.org/debian/strongswan/merge_requests/7 + - https://salsa.debian.org/debian/strongswan/merge_requests/6 + - https://salsa.debian.org/debian/strongswan/merge_requests/5 - * 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 + 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-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] In a bionic vm: $ sudo apt install strongswan 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 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. + + 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://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848890, which lead to the MRs below: - https://salsa.debian.org/debian/strongswan/merge_requests/8 - https://salsa.debian.org/debian/strongswan/merge_requests/7 - https://salsa.debian.org/debian/strongswan/merge_requests/6 - https://salsa.debian.org/debian/strongswan/merge_requests/5 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-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
