** Description changed: [ Impact ] Systems with a /var/lib/dpkg/arch file will trigger an apparmor DENIED log entry when the esm-cache service tries to access that file. Not all systems will have /var/lib/dpkg/arch. It can be created, probably among other scenarios, when a subarchitecture is added. For example, on amd64 systems, it's quite common to also have i386 added via the command sudo dpkg --add-architecture i386 That is enough to create /var/lib/dpkg/arch populated with both am64 and i386, and trigger this bug. Within the Pro client, we determined that the bug is triggered when a) that file exists; and b) when the Pro client, as part of running the esm-cache.service service, calls `apt-cache policy`. That will trigger an access to /var/lib/dpkg/arch under the dpkg and other apparmor subprofiles defined in /etc/apparmor.d/ubuntu_pro_esm_cache, and result in apparmor denying that access. After learning of this bug, we ran the upstream test suite with the bug trigger in place, without the fix, and no tests have been found that failed because of this bug (other than the check for apparmor DENIED logs). Even so, this influx of apparmor logs can be troubling and noisy, or we could have missed a scenario where it really triggers an incorrect behavior in the Pro client. Given that the fix is simple, and easy to test, we decided to proceed with this SRU. [ Test Plan ] a) very specific test for this issue - install the Pro client version to be tested - run these commands: sudo aa-exec -p ubuntu_pro_esm_cache//dpkg dpkg --print-foreign-architectures sudo aa-exec -p ubuntu_pro_esm_cache apt-cache policy Without the fix, they will produce apparmor DENIED messages in the dmesg logs showing an attempted access to /var/lib/dpkg/arch, and in addition to that, the dpkg one will fail (apt-cache policy won't fail) b) esm-cache.service test - install the Pro client version to be tested - run these commands in sequence as root: rm -rf /var/lib/apt/periodic/* service systemctl start esm-cache.service Without the fix, the dmesg logs will contain apparmor DENIED messages showing attempted accesses to /var/lib/dpkg/arch. [ 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? + A syntax error in the apparmor profile would prevent it from loading, + and remove its protection entirely. To account for that, the package + build process runs an apparmor static check on the generated profiles, + and if that fails, the package build fails. It could still be + susceptible to errors at profile load-time regarding the running kernel, + which is likely different than the running kernel in the launchpad + builders. - * 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. + Another type of mistake that could happen is inadvertently opening up + the profile more than is needed. But the extra access we are giving here + is read-only, and the affected profiles do need that access. [ Other Info ] Upstream bug report: https://github.com/canonical/ubuntu-pro- client/issues/3137 + + Unfortunately this wasn't caught by the extensive Pro test suite because + the test units (vms, lxd containers) never had a /var/lib/dpkg/arch file + in them. Likewise, the development container where this profile was + first created also didn't have that file. + [ Original Description ] ubuntu-advantage-tools 32.3~18.04 is causing a new apparmor denial on Bionic when updating: [ 8091.769560] audit: type=1400 audit(1717273124.410:121): apparmor="DENIED" operation="open" profile="ubuntu_pro_esm_cache//dpkg" name="/var/lib/dpkg/arch" pid=10358 comm="dpkg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Fix: --- /etc/apparmor.d/ubuntu_pro_esm_cache.orig 2024-06-01 22:31:28.276735437 +0200 +++ /etc/apparmor.d/ubuntu_pro_esm_cache 2024-06-01 22:31:07.163884846 +0200 @@ -174,6 +174,8 @@ /etc/dpkg/** r, + /var/lib/dpkg/** r, + /{,usr/}bin/dpkg mr, }
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2067810 Title: New Apparmor denial with ubuntu-advantage-tools on bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2067810/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
