** 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?
* 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.
[ 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 ]
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
