** Patch added: "debdiff for SRU to noble" https://bugs.launchpad.net/apparmor/+bug/2102680/+attachment/5889105/+files/apparmor_4.0.0-beta3-0ubuntu4.debdiff
** Description changed: + [ 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2102680 Title: Installation of AppArmor on a 6.14 kernel produces error message "Illegal number: yes" To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/2102680/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
