** Patch added: "debdiff for SRU to noble" https://bugs.launchpad.net/apparmor/+bug/2102680/+attachment/5889198/+files/apparmor_4.0.1really4.0.1-0ubuntu0.24.04.5.debdiff
-- 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/2102680 Title: Installation of AppArmor on a 6.14 kernel produces error message "Illegal number: yes" Status in AppArmor: Invalid Status in apparmor package in Ubuntu: Fix Released Bug description: [ Impact ] This problem causes apparmor to print an error "Illegal number: yes" on startup. Also, it thus does not properly disable `apparmor_restrict_unprivileged_userns`. [ Test Plan ] * Run: `sudo systemctl start apparmor` * Check the output of `sudo systemctl status apparmor` and/or `journalctl -eu apparmor` for "Illegal number: yes". [ Where problems could occur ] * A syntax error (or a type error similar to the original issue) in the change could cause the script to fail. This risk can be reduced by explicitly checking the script with `shellcheck /lib/apparmor/rc.apparmor.functions` and verifying no new concerns appear. (There are 7 pre-existing SC3043 warnings that "In POSIX sh, 'local' is undefined.".) * A logic error in the script could cause the restrictions (apparmor_restrict_unprivileged_userns) to A) be enabled when they should be disabled or B) disabled when they should be enabled. In this case, the code only ever disables the restrictions. So the error scenarios are that A) it would be left enabled when it should be disabled, or B) it would be disabled when it should be enabled. * For A), this would happen if the code fails to match in the scenario where it should. That is, if `"$unconfined_userns" = "0"` does not match in some scenario where `"$unconfined_userns" -eq 0` would. This is a risk, as whitespace is ignored for `-eq` but not for `=`. For example, `[ " 0 " -eq 0 ] && echo match` does in fact match. The variable is set like this: `unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0)` The `echo 0` portion will never produce whitespace. This can be tested further with: `x=$([ -f /xxx ] && cat /xxx || echo 0) ; [ "$x" = "0" ] && echo matches` The kernel does not return whitespace either. I tested on an older (18.04) system and this matched as expected: `unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0) ; [ "$unconfined_userns" = "0" ] && echo matches` * For B), this would happen if `[ "$unconfined_userns" = "0" ] || [ "$unconfined_userns" = "no" ]` somehow matches when it should not. As established above, the check for `= "0"` is slightly more strict than `-eq 0`, so that should not be an issue. This is a straightforward ORed check in shell, so that part should be fine. And `"$unconfined_userns" = "no"` is very clear and clearly `"no"` is the analog to the old `0`. [ Other Info ] * I have attached debdiffs for oracular and noble. * This uses the patch from plucky, as authored by Ryan Lee. It is unmodified on oracular, but needed a `quilt refresh` for noble. Original Description: Installing the AppArmor package on a Plucky machine that is running a 6.14 kernel produces the error message "/var/lib/dpkg/info/apparmor.postinst: 148: [: Illegal number: yes". This is due to an underlying kernel sysctl (/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns) changing from a 0/1 integer (semantic boolean) to a "no"/"yes" string in Ubuntu's 6.14 kernel, causing our debian/patches/ubuntu/userns- runtime-disable.patch to fail because it expects a 0/1 integer. The switch to "no"/"yes" will be needed if/when the sysctl is upstreamed. As such, we should patch our debian/patches/ubuntu/userns-runtime- disable.patch to be robust and handle both 0/1 and "no"/"yes" values for the sysctl. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/2102680/+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
