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)
Status changed to 'Confirmed' because the bug affects multiple users.