My bad: my bwrap error was unrelated to this bug and the kernel.
Still, I am getting the error message ("Illegal number: yes") while
starting apparmor on kernels > 6.8.0-79 (at least).
--
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 : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
