[SRU][N/O/P][PATCH 0/1] apparmor: Revert patch that allows runtime changes to feature set
Georgia Garcia
georgia.garcia at canonical.com
Tue Jan 28 19:41:53 UTC 2025
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(-)
--
2.43.0
More information about the kernel-team
mailing list