ACK: [SRU][N/O/P][PATCH 0/1] apparmor: Revert patch that allows runtime changes to feature set

[Stefan Bader]

On 28.01.25 20:41, Georgia Garcia wrote:
> BugLink: https://bugs.launchpad.net/bugs/2095370
> 
> 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.
> 
> Georgia Garcia (1):
>    UBUNTU: SAUCE: Revert "UBUNTU: SAUCE: apparmor4.0.0 [67/90]: userns -
>      add the ability to reference a global variable for a feature value"
> 
>   security/apparmor/apparmorfs.c         | 8 ++------
>   security/apparmor/include/apparmorfs.h | 6 ------
>   2 files changed, 2 insertions(+), 12 deletions(-)
> 

Acked-by: Stefan Bader <stefan.bader at canonical.com>

- Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 47863 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250213/b31bb03a/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250213/b31bb03a/attachment-0001.sig>