** Description changed: [Impact] - * An explanation of the effects of the bug on users and + * An explanation of the effects of the bug on users and - * justification for backporting the fix to the stable release. + * justification for backporting the fix to the stable release. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. [Test Plan] - * detailed instructions how to reproduce the bug + * 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. + * 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. + * if other testing is appropriate to perform before landing this update, + this should also be described here. [Where problems could occur] - * Think about what the upload changes in the software. Imagine the change is - wrong or breaks something else: how would this show up? + 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. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. - - * This must '''never''' be "None" or "Low", or entirely an argument as to why - your upload is low risk. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + 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 + * 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
