Verification completed on noble kernel 6.8.0-56.58: $ journalctl -b | grep systemd | grep -i apparmor ... Feb 20 09:50:03 sec3-noble-amd64 kernel: audit: type=1400 audit(1740055803.156:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=1 comm="systemd" Feb 20 09:50:03 sec3-noble-amd64 kernel: audit: type=1400 audit(1740055803.156:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=1 comm="systemd" Feb 20 09:50:03 sec3-noble-amd64 systemd[1]: Successfully loaded all binary profiles from AppArmor early policy cache at /etc/apparmor/earlypolicy/2693c843.0. georgia@sec3-noble-amd64:~$ uname -a Linux sec3-noble-amd64 6.8.0-56-generic #58-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 14 15:33:28 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
** Tags removed: verification-needed-noble-linux ** Tags added: verification-done-noble-linux -- 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/2095370 Title: AppArmor early policy load not funcitoning Status in apparmor package in Ubuntu: Confirmed Bug description: SRU Justification: [Impact] The commit being reverted allows the use of runtime information on AppArmor features, usually located under /sys/kernel/security/apparmor/features/ The set of features is used to calculate the features' hash, used by AppArmor in precompiled policy, to determine the set of features used to compile the profile, which is relevant for appropriate mediation of classes, such as network, userns, etc. Systemd allows the use of earlypolicy loading. It looks for precompiled policy under /etc/apparmor/earlypolicy/ during boot and loads it before starting other services. Currently, when a precompiled policy is generated, the userns restriction is enabled, but during boot, when systemd is trying to load earlypolicy, it is not - causing a mismatch in the features' hash and leading to policy not being loaded. Therefore we should not allow the use of runtime information on the features directory. [Fix] Revert the patch that allows runtime information to be available in /sys/kernel/security/apparmor/features/ And set the two values used currently to always true, to mean that the restriction is available in these kernels. To check if they are set, one should use the proc interface either by using sysctl or by checking /proc/sys/kernel/apparmor_restrict_unprivileged_userns or /proc/sys/kernel/apparmor_restrict_unprivileged_io_uring directly. [Test Plan] 1. Boot a VM and set the following settings in /etc/apparmor/parser.conf: write-cache cache-loc /etc/apparmor/earlypolicy/ 2. Reload the apparmor systemd service to generate the precompiled policy # systemctl restart apparmor 3. Check if the precompiled policy was created in /etc/apparmor/earlypolicy/ # ls /etc/apparmor/earlypolicy/ 0bb6850a.0 4. Reboot the VM 5. Check if the systemd logs contain information regarding earlypolicy being loaded: # journalctl -b | grep systemd | grep -i apparmor ... ... systemd[1]: Successfully loaded all binary profiles from AppArmor early policy cache at /etc/apparmor/earlypolicy/0bb6850a.0. ... systemd[1]: systemd 256-1ubuntu1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE) ... [Where problems could occur] Problems could occur if tools were checking under /sys/kernel/security/apparmor/features/ to see if the restrictions were enabled. As far as the AppArmor team is aware, that's not the case. All tools that are checking the restrictions, like AppArmor itself, or LXD, are using the /proc/ interface. --- Original description: Profile cache files in /etc/apparmor/earlypolicy/ should be loaded by systemd during early boot to enable full system confinement. Systemd should load the cache and try to enter confinement as documented in https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorInSystemd However this is not happening on noble. The early policy is not being loaded and systemd does not appear to attempt to enter the systemd profile, which should result in the following error if the systemd profile is not part of the early cache set. Failed to change to AppArmor profile 'systemd'. Please ensure that one of the binary profile files in policy cache directory /etc/apparmor/earlypolicy/XXXXX contains a profile with that name." systemd on boot does report that it has been built with apparmor support [ 2.011794] systemd[1]: systemd 257-2ubuntu1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2095370/+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
