I am confused because I thought I had already approved an FFe for this
feature. Did I imagine this? Did that FFe not cover the whole scope?
The hour is getting late now.
** Changed in: apparmor (Ubuntu)
Status: New => Incomplete
--
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:
Incomplete
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 : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
