[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux-raspi/6.8.0-1028.32 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-raspi' to 'verification-done-noble- linux-raspi'. If the problem still exists, change the tag 'verification- needed-noble-linux-raspi' to 'verification-failed-noble-linux-raspi'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-raspi-v2 verification-needed-noble-linux-raspi -- 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/X 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 +LIBCRYPTSET
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux- aws-6.11/6.11.0-1013.14~24.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux- aws-6.11' to 'verification-done-noble-linux-aws-6.11'. If the problem still exists, change the tag 'verification-needed-noble-linux-aws-6.11' to 'verification-failed-noble-linux-aws-6.11'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-aws-6.11-v2 verification-needed-noble-linux-aws-6.11 -- 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/X 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 +KM
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux-azure- nvidia/6.8.0-1014.15 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-azure-nvidia' to 'verification-done-noble-linux-azure-nvidia'. If the problem still exists, change the tag 'verification-needed-noble-linux-azure-nvidia' to 'verification-failed-noble-linux-azure-nvidia'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-azure-nvidia-v2 verification-needed-noble-linux-azure-nvidia -- 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/X 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 +IDN
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux- nvidia-6.11/6.11.0-1005.5 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-nvidia-6.11' to 'verification-done-noble-linux-nvidia-6.11'. If the problem still exists, change the tag 'verification-needed-noble-linux-nvidia-6.11' to 'verification-failed-noble-linux-nvidia-6.11'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-nvidia-6.11-v2 verification-needed-noble-linux-nvidia-6.11 -- 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/X 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
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
Verified that the patch was applied to branch linux-nvidia- tegra/6.8.0-1004.4 ** Tags removed: verification-needed-noble-linux-nvidia-tegra ** Tags added: verification-done-noble-linux-nvidia-tegra -- 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/X 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
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux-nvidia-tegra- pvw/6.8.0-1005.5 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-nvidia-tegra-pvw' to 'verification-done-noble-linux-nvidia-tegra-pvw'. If the problem still exists, change the tag 'verification-needed-noble-linux-nvidia-tegra- pvw' to 'verification-failed-noble-linux-nvidia-tegra-pvw'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-nvidia-tegra-pvw-v2 verification-needed-noble-linux-nvidia-tegra-pvw -- 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/X 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
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux-nvidia- tegra/6.8.0-1004.4 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-nvidia-tegra' to 'verification-done-noble-linux-nvidia-tegra'. If the problem still exists, change the tag 'verification-needed-noble-linux-nvidia-tegra' to 'verification-failed-noble-linux-nvidia-tegra'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-nvidia-tegra-v2 verification-needed-noble-linux-nvidia-tegra -- 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/X 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
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
Verification completed on oracular linux-intel/6.11.0-1008.8 user@sec-oracular-amd64:~$ uname -a Linux sec-oracular-amd64 6.11.0-1008-intel #8 SMP PREEMPT_DYNAMIC Wed Mar 19 16:31:19 CET 2025 x86_64 x86_64 x86_64 GNU/Linux user@sec-oracular-amd64:~$ journalctl -b | grep systemd | grep -i apparmor [...] Mar 20 17:53:10 sec-oracular-amd64 systemd[1]: Successfully loaded all binary profiles from AppArmor early policy cache at /etc/apparmor/earlypolicy/0bb6850a.0. Mar 20 17:53:10 sec-oracular-amd64 systemd[1]: systemd 256.5-2ubuntu3.1 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) ** Tags removed: verification-needed-oracular-linux-intel ** Tags added: verification-done-oracular-linux-intel -- 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/X contains a profile with that name." systemd on boot does report that it has been built with apparmor support [2.011794] sys
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux-intel/6.11.0-1008.8 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-oracular-linux-intel' to 'verification-done- oracular-linux-intel'. If the problem still exists, change the tag 'verification-needed-oracular-linux-intel' to 'verification-failed- oracular-linux-intel'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-oracular-linux-intel-v2 verification-needed-oracular-linux-intel -- 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/X 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 +LIBCRYPT
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
Verification completed on oracular linux/6.11.0-21.21 georgia@sec-oracular-amd64:~$ uname -a Linux sec-oracular-amd64 6.11.0-21-generic #21-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 19 16:50:40 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux georgia@sec-oracular-amd64:~$ journalctl -b | grep systemd | grep -i apparmor ... Feb 27 10:23:17 sec-oracular-amd64 kernel: audit: type=1400 audit(1740662597.247:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=1 comm="systemd" Feb 27 10:23:17 sec-oracular-amd64 systemd[1]: Successfully loaded all binary profiles from AppArmor early policy cache at /etc/apparmor/earlypolicy/0bb6850a.0. ** Tags removed: verification-needed-oracular-linux ** Tags added: verification-done-oracular-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/X 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 +LIBCRYPTSETU
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux/6.11.0-21.21 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-oracular-linux' to 'verification-done-oracular- linux'. If the problem still exists, change the tag 'verification- needed-oracular-linux' to 'verification-failed-oracular-linux'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-oracular-linux-v2 verification-needed-oracular-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/X 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 +PCR
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
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/X 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 +
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
This bug is awaiting verification that the linux/6.8.0-56.58 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux' to 'verification-done-noble-linux'. If the problem still exists, change the tag 'verification-needed-noble- linux' to 'verification-failed-noble-linux'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-v2 verification-needed-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/X 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 +P11K
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
** Description changed: + 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. + 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/X 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) -- 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
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
The bug was caused by a commit [1] in the Ubuntu kernel that would change the kernel features hash based on the status of the userns and io_uring restriction. When the policy cache was generated, userns restriction would be available and the hash under /etc/apparmor/earlypolicy/ would match the set of features with userns enabled, but when systemd executed at boot, the permission was disabled, causing the hash mismatch, so no policy would be loaded. [1] https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/noble/commit/?id=8bd4ee319a029669787588e648bce3c28adf4369 -- 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: 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/X 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
[Touch-packages] [Bug 2095370] Re: AppArmor early policy load not funcitoning
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: apparmor (Ubuntu) Status: New => Confirmed -- 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: 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/X 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
