[2.11.0-rc2] recent Focal releases include an ubuntu_pro_apt_news that AppArmor blocks

[cfm]

Description

As of at least https://portal.cloud.hashicorp.com/vagrant/discover/bento/ubuntu-20.04/versions/202407.23.0, AppArmor blocks Ubuntu's ubuntu_pro_apt_news utility.

Steps to Reproduce

Clean installation of SecureDrop 2.11.0-rc2 on VMs.

Expected Behavior

securedrop-admin verify succeeds on a fresh installation.

Actual Behavior

app/test_apparmor.py::test_aa_no_denies_in_syslog[paramiko:/app-prod] fails with:

Dec 12 20:06:26 vagrant kernel: [  601.238137] audit: type=1400 audit(1734033986.216:51): apparmor="DENIED" operation="mknod" profile="ubuntu_pro_apt_news" name="/tmp/clearsigned.message.wDEJWz" pid=13693 comm="python3" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

The preceding log entries are:

Dec 12 20:06:25 app-prod systemd[1]: Starting Update APT News...
Dec 12 20:06:25 app-prod systemd[1]: Starting Update the local ESM caches...

Comments

• Bug: apt_news wants to write to /var/cache/apt, apparmor blocks it canonical/ubuntu-pro-client#3193

[legoktm]

I'm going to remove this from the 2.11.0 milestone just because this is a regression in an Ubuntu package + apparmor profile and there's nothing for us to fix even if we wanted to. And there's no impact to SD systems aside from the log entry.

[cfm]

Good call, @legoktm. The preceding log entries you asked for are from immediately after boot, which confirms that this is an upstream bug and not SecureDrop-involved at all, except that it violates our expectation of no AppArmor denials. Feel free to close outright.

[legoktm]

OK cool, so presumably whenever Ubuntu (or bento?) creates new VM images with an updated ubuntu-pro-client, it'll go away. And we don't see it on prod systems (AFAIK) because the installer upgrades packages before rebooting, so it's already fixed by then.

I'm going to leave this open because I expect we're going to add a suppression of some kind in the test because it's still an issue on our noble staging job.

[legoktm]

I've added a fix for this into #7360.