Enable unprivileged user namespace restrictions by default

[Georgia Garcia]

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.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 4.0.0~alpha2-0ubuntu7

---------------
apparmor (4.0.0~alpha2-0ubuntu7) noble; urgency=medium

  [Alex Murray]
  * Enable user namespace restrictions by default (LP: #2046477)
    - d/p/u/userns-runtime-disable.patch: add logic to disable user
      namespace restrictions if kernel lacks support
    - debian/usr/lib/sysctl.d/10-apparmor.conf: set sysctl value to 1 and
      update comment to match
    - debian/apparmor.service: run After systemd-sysctl.service

  [John Johansen]
  * Add additional AppArmor profiles to support third-party applications
    that use unprivileged user namespace
    - add d/p/u/oot-unconfined-profiles.patch
    - add profiles to debian/apparmor.install
       - /etc/apparmor.d/1password
       - /etc/apparmor.d/Discord
       - /etc/apparmor.d/MongoDB_Compass
       - /etc/apparmor.d/code
       - /etc/apparmor.d/firefox
       - /etc/apparmor.d/github-desktop
       - /etc/apparmor.d/obsidian
       - /etc/apparmor.d/opera
       - /etc/apparmor.d/polypane
       - /etc/apparmor.d/signal-desktop
       - /etc/apparmor.d/slack
       - /etc/apparmor.d/steam

  [Alex Murray]
  * Drop duplicate profiles for usr.share.code.bin.code and
  * usr.lib.multiarch.opera.opera since they are now also in
    d/p/u/oot-unconfined-profiles.patch
    - modified d/p/u/userns-unconfined-profiles.patch to remove them
    - removed from debian/apparmor.install
    - added to debian/apparmor.maintscript to ensure they are removed on
      upgrade

 -- John Johansen <email address hidden> Wed, 13 Dec 2023 20:38:45 -0800

[Dimitri John Ledkov (xnox)]

Can you please explain how all of this is handled during dist-upgrades?

Have all the packages with affected profiles have versioned depends added?

Is the featured _not_ turned on during dist-upgrade from jammy hwe to noble, but only after reboot? (as the kernel is compatible, yet during upgrade the profiles may not be updated in the correct order)

[John Johansen (jjohansen)]

We will get this updated with requested information soon. We are currently working on a revision that provides more flexibility and will support some cases that break today.

[Martin Pitt (pitti)]

Just to make sure that we really talk about the same thing: This bug sounds like it is *intended* that

    unshare --user --map-root-user /bin/bash -c whoami

(as unpriv user) now fails in current Ubuntu 24.04 noble. That still worked in released 23.10.

I am starting to test Cockpit on the current noble dailies [1] to make sure everything is ready for 24.04 LTS (as 23.10 was a bit of a disaster..), and aside from some non-fatal AppAmor noise this is the most important issue. This breaks /usr/lib/cockpit/cockpit-desktop , which uses an user namespace to isolate cockpit's web server + a browser, and that isolation is absolutely crucial for its security.

I can update cockpit-ws.deb to ship a new file /etc/apparmor.d/cockpit-desktop with

------ 8< -----------
abi <abi/4.0>,

include <tunables/global>

profile cockpit-desktop /usr/lib/cockpit/cockpit-desktop flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/cockpit-desktop>
}
------ 8< -----------

I confirmed that this works fine. I just wanted to check that this is intended, and not circumventing your intentions here?

Thanks!

[1] https://github.com/cockpit-project/bots/pull/6048

[corrado venturini (corradoventu)]

apparmor 4.0.0~beta2-0ubuntu3 installed today from proposed solves problem of bug https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/2047256, does it solve other problems too?
Thanks

[John Johansen (jjohansen)]

It solves several problems, but not all.

With regard to unprivileged user namespace mediation it should fix
 - mscode
 - nautilis
 - devhelp
 - element-desktop
 - piphany
 - evolution
 - keybase
 - opam

the element-desktop is still known to have some issues, which are on the snapd side. It needs to add some interfaces etc.

there is a beta3 coming early next week with additional fixes coming. The full set won't be finalized until beta3 is rolled this weekend.

[John Johansen (jjohansen)]

@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.