Hey Alex! This FFe mentions requiring a newer kernel. Do we know the ETA of that?
-- 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/2036128 Title: [FFe] enable unprivileged user namespace restrictions by default for mantic Status in apparmor package in Ubuntu: New Bug description: As per https://discourse.ubuntu.com/t/spec-unprivileged-user- namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626, unprivileged user namespace restrictions for Ubuntu 23.10 are to be enabled by default via a sysctl.d conf file in apparmor. In https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035315 new apparmor profiles were added to the apparmor package for various applications which require unprivileged user namespaces, using a new unconfined profile mode. To support this an additional change was added to the mantic kernel in https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/mantic/commit?h=master- next&id=7327726a2dbf571e05f7c095916dcce0347790b4 which is still currently unreleased. Without this kernel change, if userns restrictions are enabled the existing policies added above will not actually work to allow them to be used by the various applications. As such we need to ensure that userns restrictions are not enabled via sysctl when this feature is not present / enabled. Whilst it may be possible to capture the dependency logic via `Breaks:` or similar, this would not help in the case that a user booted into an older kernel with the new apparmor userspace package. As such, as well as enabling the sysctl via the sysctl.d conf file, it is proposed to add logic into the apparmor.service systemd unit to check that the kernel supports the aforementioned unconfined profile mode and that it is enabled - and if not then to force disable the userns restrictions sysctl via the following logic: userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns) unconfined_userns=$([ -f /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] && cat /sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || echo 0) if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then if [ "$unconfined_userns" -eq 0 ]; then # userns restrictions rely on unconfined userns to be supported echo "disabling unprivileged userns restrictions since unconfined userns is not supported / enabled" sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 fi fi this allows a local admin to disable the sysctl via the regular sysctl.d conf approach, but to also make sure we don't inadvertently enable it when it is not supported by the kernel. This proposed change has been tested via the QA Regression Testing project, in particular with the specific test added in https://git.launchpad.net/qa-regression- testing/commit/?id=6f2c5ab7c8659174adac772ce0e894328bb5045d This produces the following output, confirming the fallback works as expected on the current mantic kernel (which does not fully support the userns restrictions): ------------------------------------------------------------------------------- Running test: './test-apparmor.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-5.5 (Ubuntu 6.5.0-5.5-generic 6.5.0)' arch: 'amd64' init: 'systemd' uid: 0/0 SUDO_USER: 'ubuntu') test_unconfined_userns (__main__.ApparmorTest.test_unconfined_userns) Test that unconfined userns restrictions are applied ... Skipping private tests WARN: kernel rate limiting in effect Disabling ratelimiting until the next reboot. To renable, run: # sysctl -w kernel.printk_ratelimit=5 (enabling userns restrictions) (restarting apparmor) (checking userns restrictions got disabled) ok ---------------------------------------------------------------------- Ran 1 test in 0.232s OK ------------------------------------------------------------------------------- Also we can see on a fresh-boot with this new version installed that apparmor.service shows it has disabled the sysctl before loading any profiles even though the conf file has it enabled - and finally we can see that unshare -U works as expected: root@sec-mantic-amd64:~# uptime 07:04:48 up 0 min, 0 user, load average: 0.00, 0.00, 0.00 root@sec-mantic-amd64:~# journalctl -b0 --unit apparmor.service --no-pager Sep 15 07:04:47 sec-mantic-amd64 systemd[1]: Starting apparmor.service - Load AppArmor profiles... Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: Restarting AppArmor Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: disabling unprivileged userns restrictions since unconfined userns is not supported / enabled Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[320]: kernel.apparmor_restrict_unprivileged_userns = 0 Sep 15 07:04:47 sec-mantic-amd64 apparmor.systemd[308]: Reloading AppArmor profiles Sep 15 07:04:47 sec-mantic-amd64 systemd[1]: Finished apparmor.service - Load AppArmor profiles. root@sec-mantic-amd64:~# sysctl kernel.apparmor_restrict_unprivileged_userns kernel.apparmor_restrict_unprivileged_userns = 0 root@sec-mantic-amd64:~# grep "^[^#]" /usr/lib/sysctl.d/10-apparmor.conf kernel.apparmor_restrict_unprivileged_userns = 1 root@sec-mantic-amd64:~# sudo -iu ubuntu unshare -U id uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2036128/+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
