@pitti: yes this intended. At this stage we are essentially enumerating the known users of unprivileged user namespaces. We can ship the profile for you or you are welcome to ship it.
In the future this is going to gradually tighten, some of the "unconfined" profiles will be developed into real profiles, unconfined (including these profiles) will get tied into integrity checks, or require user exceptions in the security center, etc. -- 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/2046477 Title: Enable unprivileged user namespace restrictions by default Status in apparmor package in Ubuntu: Triaged 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, and for that to happen, the restrictions need to be enabled for 24.04 When the unprivileged user namespace restrictions are enabled, various applications within and outside the Ubuntu archive fail to function, as they use unprivileged user namespaces as part of their normal operation. A search of the Ubuntu archive for the 23.10 release was performed looking for all applications that make legitimate use of the CLONE_NEWUSER argument, the details of which can be seen in https://docs.google.com/spreadsheets/d/1MOPVoTW0BROF1TxYqoWeJ3c6w2xKElI4w-VjdCG0m9s/edit#gid=2102562502 For each package identified in that list, an investigation was made to determine if the application actually used this as an unprivileged user, and if so which of the binaries within the package were affected. The full investigation can be seen in https://warthogs.atlassian.net/browse/SEC-1898 (which is unfortunately private) but is summarised to the following list of Ubuntu source packages, as well as some out-of-archive applications that are known to use unprivileged user namespaces. For each of these binaries, an apparmor profile is required so that the binary can be granted use of unprivileged user namespaces - an example profile for the ch-run binary within the charliecloud package is shown: $ cat /etc/apparmor.d/ch-run abi <abi/4.0>, include <tunables/global> profile ch-run /usr/bin/ch-run flags=(unconfined) { userns, # Site-specific additions and overrides. See local/README for details. include if exists <local/ch-run> } However, in a few select cases, it has been decided not to ship an apparmor profile, since this would effectively allow this mitigation to be bypassed. In particular, the unshare and setns binaries within the util-linux package are installed on every Ubuntu system, and allow an unprivileged user the ability to launch an arbitrary application within a new user namespace. Any malicious application then that wished to exploit an unprivileged user namespace to conduct an attack on the kernel would simply need to spawn itself via `unshare -U` or similar to be granted this permission. Therefore, due to the ubiquitous nature of the unshare (and setns) binaries, profiles are not planned to be provided for these by default. Similarly, the bwrap binary within bubblewrap is also installed by default on Ubuntu Desktop 24.04 and can also be used to launch arbitrary binaries within a new user namespace and so no profile is planned to be provided for this either. In 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. They were also added in the AppArmor upstream project. 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 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046477/+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
