You don't *have* to include the full output of the test cases when verifying a bug (although, depending on how much output there is, it can be nice).
I don't think it was clear that you *had* gone through the full test- case in your verification comment - I'm not entirely sure what gave that impression, but I think it might have been the combination of *some* output (the apt/dpkg bit) and saying “the bug is fixed, thanks” without making reference to the test case. Thanks for testing! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1872564 Title: /proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice Status in apparmor package in Ubuntu: Fix Released Status in apparmor source package in Focal: Fix Released Bug description: [Impact] On a default Focal install, systemd is used when looking up passwd and group information: # grep systemd /etc/nsswitch.conf passwd: files systemd group: files systemd Daemons confined by Apparmor that also query those "databases" will cause this Apparmor denial: audit: type=1400 audit(1586825456.411:247): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=7370 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000 Many daemons confined by Apparmor also happen to downgrade their privileges so they always end up looking up user/group information. To fix this problem, we had to backport an upstream patch which adds new directives to the 'nameservices' apparmor profile. [Test Case] In order to reproduce the bug, one can: 1) launch a Focal container (named fb1 here) $ lxc launch images:ubuntu/focal fb1 2) setup apparmor inside the container (already done on official Ubuntu images) $ lxc exec fb1 -- apt update && lxc exec fb1 -- apt install apparmor -y 3) install bind9 $ lxc exec fb1 -- apt install bind9 -y 4) check kernel logs for DENIED $ journalctl -o cat -b0 -k | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"' or, depending on how logging is configured: $ dmesg | grep 'apparmor="DENIED"' | grep -F 'profile="/usr/sbin/named"' Step 4, should not return anything. Because systemd is involved in the user/group lookups, it currently returns the following: audit: type=1400 audit(1586826072.115:266): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000 audit: type=1400 audit(1586826072.115:267): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000 audit: type=1400 audit(1586826072.115:268): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000 audit: type=1400 audit(1586826072.115:269): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000 audit: type=1400 audit(1586826072.115:270): apparmor="DENIED" operation="open" namespace="root//lxd-fb1_<var-snap-lxd-common-lxd>" profile="/usr/sbin/named" name="/proc/sys/kernel/random/boot_id" pid=13756 comm="named" requested_mask="r" denied_mask="r" fsuid=1000000 ouid=1000000 [Regression Potential] In order to fix this issue, 3 separate patches had to be backported. They are simple and self-contained, especially two of them, whose purposes are to add the definition of the @{run} variable and then to add a trailing slash at the end of the "/run" pathname. The other patch, albeit very simple, adds three statements to the 'nameservice' profile in order to let processes access (read-only) files under "/run/systemd/userdb" and "/proc/sys/kernel/random/boot_id". After thinking about the possible cases, the only possible problem I could envision was for a program that, not being able to access some of these files before, will now be able to do that and therefore exercise a part of its codebase which was not being used, possibly uncovering latent bugs in this software. But this is not a regression of apparmor per se. [Original Description] (Description and Test Case were moved above) # Workaround 1) remove systemd from nsswitch.conf $ lxc exec fb1 -- sed -i 's/ systemd$/ # systemd/' /etc/nsswitch.conf 2) restart named $ lxc exec fb1 -- service named restart 3) notice no more denials in kernel logs # Additional information root@fb1:~# apt-cache policy apparmor apparmor: Installed: 2.13.3-7ubuntu4 Candidate: 2.13.3-7ubuntu4 Version table: *** 2.13.3-7ubuntu4 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages 100 /var/lib/dpkg/status root@fb1:~# uname -a Linux fb1 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux root@fb1:~# lsb_release -rd Description: Ubuntu Focal Fossa (development branch) Release: 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
