AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP

[Xavier Guillot]

Hi, I run Ubuntu development branch 24.04 and I have a problem with Epiphany browser 45.1-1 (Gnome Web): program doesn't launch, and I get this error

$ epiphany
bwrap: Creating new namespace failed: Permission denied

** (epiphany:12085): ERROR **: 14:44:35.023: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1
Trappe pour point d'arrêt et de trace (core dumped)

$ epiphany
bwrap: Creating new namespace failed: Permission denied

** (epiphany:30878): ERROR **: 22:22:26.926: Failed to fully launch dbus-proxy: Le processus fils s’est terminé avec le code 1
Trappe pour point d'arrêt et de trace (core dumped)

Thanks for your help!

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Xavier Guillot (valeryan-24)]

It seems that it affects many Gnome programs: there are other bugs on Launchpad for 24.04 and Evolution, Gnome Packagekit with the "core dumped" error

[Aaron Rainbolt (arraybolt3)]

This is affecting Falkon and qutebrowser as well. Just now me and a couple of the Lubuntu devs did a deep debugging session and found the issue.

About four days ago, an upload was made in AppArmor that no longer allows unprivileged programs to create user namespaces. See https://launchpad.net/ubuntu/+source/apparmor/4.0.0~alpha2-0ubuntu7 and https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046477. As it turns out, Epiphany, Falkon, and qutebrowser (and it sounds like Evolution and something related to PackageKit) all use these features. When something tries to create a user namespace and fails, apparently it can result in a SIGTRAP pretty quickly.

2023-12-19T14:43:35.821206-05:00 user-standardpc kernel: [ 2092.018163] audit: type=1400 audit(1703015015.816:119): apparmor="DENIED" operation="userns_create" class="namespace" info="User namespace creation restricted" error=-13 profile="unconfined" pid=4348 comm="falkon" requested="userns_create" denied="userns_create"
2023-12-19T14:43:35.821230-05:00 user-standardpc kernel: [ 2092.018657] traps: falkon[4348] trap int3 ip:7f196dbd7b13 sp:7ffea3141ea0 error:0 in libQt5WebEngineCore.so.5.15.15[7f196b9b4000+6931000]

First the failure to make the namespace, then the breakpoint trap.

This can be worked around trivially but very, very dangerously by disabling sandboxing (using QTWEBENGINE_DISABLE_SANDBOX=1 for Falkon and qutebrowser, or WEBKIT_DISABLE_SANDDBOX_THIS_IS_DANGEROUS=1 for Epiphany). This hint led us to the source of the issue.

Accroding to the AppArmor bug report, "For each of these binaries, an apparmor profile is required so that the binary can be granted use of unprivileged user namespaces". So... I guess that means we have many packages that need AppArmor profiles now.

[Aaron Rainbolt (arraybolt3)]

This bug also breaks Electron-based AppImages, such as Balena Etcher. While we specifically don't support these apps, I find it very likely that Ubuntu has potentially hundreds of thousands of users of these kinds of apps.

[John Johansen (jjohansen)]

Hey Aaron, yes there are many packages that now require an apparmor profile. There is a shortcut, in between profile that can be used atm so that a full profile doesn't need to be developed to get applications that require unprivileged user namespaces working. I will get a patch together to add these to the set of known applications that need unprivileged user namespaces that we are now shipping profiles for.

You should be able to fix your immediate issues by adding the following to your system,

$ cat /etc/apparmor.d/falkon
abi <abi/4.0>,
include <tunables/global>

profile falkon /usr/bin/falkon flags=(unconfined) {
  userns,

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

$ cat /etc/apparmor.d/epiphany
abi <abi/4.0>,
include <tunables/global>

profile epiphany /usr/bin/epiphany flags=(unconfined) {
  userns,

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

$ cat /etc/apparmor.d/qutebrowser
abi <abi/4.0>,
include <tunables/global>

profile qutebrowser /usr/bin/qutebrowser flags=(unconfined) {
  userns,

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

and then reloading your profiles via.
$ sudo systemctl reload apparmor

[Aaron Rainbolt (arraybolt3)]

Thanks! I'll be on the hunt for any more that act like this and add them to the report. I'm also happy to help prep uploads (I'm not an MOTU yet so I can't upload on my own, but I can prep the packaging).

[John Johansen (jjohansen)]

Yes it is known that Electron based apps are broken by this, it is unfortunate but there is no getting around it if we are going to tighten security around unprivileged user namespaces.

As for apps that we don't specifically support (Electron or otherwise), we are still adding profiles for as many of them as we can, so please report them.

[Aaron Rainbolt (arraybolt3)]

Nice! This works with AppImages? If so, I think we have a perfect solution.

[John Johansen (jjohansen)]

It does work for AppImages, but it is weird in that they don't have an install location, so that has to be adjusted for where they are placed on the system, or we have to set a security xattr on the executable at the time it is chmoded to +x

Admittedly orcaslicer doesn't use unprivileged user namespaces, but for it works for an example of how to put one of these on it.

abi <abi/4.0>,
include <tunables/global>

profile orcaslicer /home/jj/Desktop/OrcaSlicer_Linux_V1.8.1.AppImage flags=(unconfined) {
  userns,

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

or we could make that looser by doing something like

abi <abi/4.0>,
include <tunables/global>

profile orcaslicer @{bin}/OrcaSlicer_Linux_V1.8.1.AppImage flags=(unconfined) {
  userns,

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

or by setting the security.apparmor label on the binary

sudo setfattr -h -n security.apparmor -v orcaslicer /PATH/TO/APPIMAGE

and doing

abi <abi/4.0>,
include <tunables/global>

profile orcaslicer xattrs=(security.apparmor=orcaslicer) flags=(unconfined) {
  userns,

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

[Aaron Rainbolt (arraybolt3)]

How acceptable or possible would a solution be that had one universal "allowUserNamespaces" attribute in an AppArmor config that could then simply be set on whatever files one wanted to enable the features on? That would support all third-party apps that a user deemed worthy without needing much effort to enable but without allowing programs to enable it themselves without root privileges, if I'm understanding correctly.

[Aaron Rainbolt (arraybolt3)]

I can't seem to get the xattr solution to work. I'm trying it on a normal binary and it's failing like so:

# Contents of /etc/apparmor.d/falkon
abi <abi/4.0>,
include <tunables/global>

profile falkon xattrs=(security.apparmor=falkon) flags=(unconfined) {
  userns,
  include if exists <local/falkon>
}

# setfattr command
user@user-standardpc:/usr/bin$ sudo setfattr -n security.apparmor -v falkon /usr/bin/falkon

# make sure the attribute is set
user@user-standardpc:/usr/bin$ getfattr -n security.apparmor /usr/bin/falkon
getfattr: Removing leading '/' from absolute path names
# file: usr/bin/falkon
security.apparmor="falkon"

# attempt to launch
user@user-standardpc:/usr/bin$ /usr/bin/falkon
[3967:3967:1220/095728.818079:FATAL:credentials.cc(125)] Check failed: . : Permission denied (13)
Trace/breakpoint trap (core dumped)

#checking the logs
user@user-standardpc:/usr/bin$ journalctl -n100
...
Dec 20 09:57:28 user-standardpc kernel: audit: type=1400 audit(1703084248.814:826): apparmor="DENIED" operation="userns_create" class="namespace" info="User namespace creation restricted" error=-13 profile="unconfined" pid=3967 comm="falkon" requested="userns_create" denied="userns_create"
Dec 20 09:57:37 user-standardpc kernel: traps: falkon[3967] trap int3 ip:7f3ae85d7b13 sp:7ffe61e8b700 error:0 in libQt5WebEngineCore.so.5.15.15[7f3ae63b4000+6931000]
...

The solution that involves spelling out the absolute path to the file does work.

[John Johansen (jjohansen)]

Unfortunately it has to be a privileged operation, otherwise any application could set the attribute and then have access to user namespaces. The problem with unprivileged user namespaces is that it makes privileged interfaces available to the user in ways that they weren't designed for, leading to vulnerabilities. Yes it tries to mitigate and control this in some ways, but the reality is the kernel is always adding new interfaces that are privileged, so its a game of whack-a-mole.

To quote Linus about adding user namespaces "it was a mistake. We're stuck with it". This is just an after the fact mitigation, and as such there is going to be a somewhat painful transition period.

There is another reason to not use a single attribute as well. This is a stepping stone to bringing much tighter/finer confinement to the desktop. Having unique labels on the applications will allow us to start deploying finer controls over who can talk to who. This is really important when one of those entities have elevated privileges, which is the case for applications making use of unprivileged user namespaces.

[John Johansen (jjohansen)]

RE: security.apparmor attribute attachment not working

Sorry for the current version of apparmor in Ubuntu requires a path attachment as well, you need to change the profile to (caveat untested so I may have made another mistake too)

profile falkon /** xattrs=(security.apparmor=falkon) flags=(unconfined) {
  userns,
  include if exists <local/falkon>
}

[Aaron Rainbolt (arraybolt3)]

The reason I was suggesting a single attribute to enable user namespace creation is because of the myriad of third-party apps that we probably *aren't* going to catch here that users use out there that require user namespace privileges. For instance, there are probably at least some QtWebEngine-based web browsers that aren't in the archive and that we will never hear of until someone complains that they're broken. Many other apps may need these same privileges for whatever reason. It seems odd to expect users to write custom AppArmor policies for each of these, and it seems unrealistic to think we're going to be able to simply catch them as they pop up - SRU updates don't go fast enough for this to be practical in most instances. Having the ability for an end-user to simply set an attribute and be done seems like it would still be secure (you have to have root privileges to set the attribute), and simple enough for someone to Google and find the fix, or ask in an Ubuntu support room and be provided a one-line fix.

We can use fine-grained controls all we want *in* Ubuntu. It's the users who have to extend those controls that I'm thinking about.

I'll test the latest attribute attachment profile you suggested. Thanks!

[John Johansen (jjohansen)]

Agreed we can't ask for a user to create a profile for every application, apparmor profiles can be shared, and having a generic profile that can be opted into makes sense. We are working towards it, this is just the first iteration. One of the things we are working on is abstracting what the current set needs in the way of permissions so we can refine the profiles. Some will remain individual application profiles some will become more generic as this evolves.

One of the things that will help is if we can move this from an esoteric log message to a user prompt. We want to be really careful with user prompts but once we have the main set of applications covered prompting the user that the application requires this additional permission, similar to how Mac's ask about whether you really want to run an application downloaded from the internet, and doing the profile setup/tagging in the backgound instead of having the user do it makes this a lot more usable.

[Aaron Rainbolt (arraybolt3)]

User prompting sounds like a good idea. Tt fixes one concern I wanted to bring up, which is developers who use user namespaces in their code (possibly indirectly by using QtWebEngine for instance). Those devs would end up with their software crashing for no apparent reason. A user prompt or descriptive crash message of some sort would get around that problem.

[John Johansen (jjohansen)]

There is another improvement coming before prompt that may (it will depend on the sandbox) also take care of many of the browser sandbox issues, as well as a few other uses of unprivileged user namespaces. On user namespace creation we will be able to transition the profile to a new profile with a reduced set of privileges. Having a catch-all profile that allows creation of user namespaces for a sandbox that doesn't need any elevated privileges but is instead just being used to achieve, pid and uid separation.

[Erich Eickmeyer (eeickmeyer)]

Added plasma-desktop. A prompt, as proposed, would not be a solution for this as it seems the entire desktop envirtonment, in this case, is bugged. Simply adding a web browser widget or picture frame to the desktop, both of which use QtWebEngine and are not separate components but built-in components of plasma-desktop, means that this change has broken the entirety of plasma-desktop.

[Rik Mills (rikmills)]

Erich: Actually the web browser widget or picture frame are from the kdeplasma-addons source. So not a core part of the Plasma desktop. We just seed those addons packages by default as they are good to have for users. However, you are correct that when installed and a user tries to add them to the desktop, the resulting crash does bring down the whole desktop.

[John Johansen (jjohansen)]

kdeplasma should be a fairly easy fix without prompting. I'll work on a profile for it and its add-ons

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dan Simmons (kc2bez)]

Other packages that have been tested and found to be impacted by this bug have been added.

[John Johansen (jjohansen)]

Sorry for the delay on this, we had some bugs to chase down. The following PPA has an update to how user namespace mediation is being handled. For the unconfined case there are two options

1. If the unprivileged_userns profile does not exist, unprivileged user namespace creation is denied as before.

2. If the unprivileged_userns profile exists (ie. is loaded into the kernel), unprivileged user namespace creation is allowed an will result in a transition into the unprivileged_userns profile. The unprivileged_userns profile with then deny all capabilities within the profile. Execution of applications is allowed within the unprivileged_userns profile but, they will result in a stack with the unprivileged_userns profile, that is to say the unprivileged_userns profile can not be dropped (capabilities can not be gained).

There is still some additional functionality to land that will give profile authors more control, but what is present here should be enough to start testing.

https://launchpad.net/~apparmor-dev/+archive/ubuntu/unprivileged-userns

Note: the apparmor_restriction_unprivileged_unconfined needs to be enabled to test the above user namespace behavior. See https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction

[Scarlett Gately Moore (scarlettmoore)]

I have tested the above packages and created a profile for kontact locally and kontact no longer crashes hooray. I am still sorting out what I need to do here for the kde packages ( returning after a long time gone ) Is there a package I need to add new profiles or is someone else adding the new profiles? SO sorry for my newbness.

[John Johansen (jjohansen)]

We have found that allowing the user namespace creation, and then denying capabilities is in general handled much better by KDE. The the case of the plasmashell and the browswer widget denying the creation of the user namespace would cause a crash with a SIGTRAP backtrace, where allowing the creation of the userns and then denying capabilities within the user namespace would result in the browser widget falling back to a sandbox that didn't use user namespaces, not ideal but better than a crash. To make sure the widget was using the full sandbox we gave it a profile (see QtWebEngineProcess in /etc/apparmor.d/plasmashell).

The apparmor package is adding a base set of profiles, including one for the plasmashell and the unprivileged_userns profile.

We are willing to carry profiles in the apparmor package but are also happy for other packages to carry them. Generally speaking, having the profile carried in the package means its easier for the package maintainer to update the profile, if that is something the package maintainer is willing to do.

We are more than willing to take in profiles and patches to profiles, or allow a maintainer to claim some profiles and move them out of the apparmor package. What ever is best for the maintainer.

AppArmor does have a second set of profiles that are not installed by default in the apparmor-profiles package. These profiles once installed are not enabled by default but must be selectively enabled by the user. If you are looking for a broader set of profiles as a base to start from there is also the apparmor.d project https://github.com/roddhjav/apparmor.d. They aren't tuned for ubuntu but they can be a good starting point if a profile is needed.

Note: the current apparmor package doesn't allow you to specify the userns transition in policy. A new version of the apparmor package is coming that will allow it.

[Scarlett Gately Moore (scarlettmoore)]

Thank you so much for the information! I am going to go with putting them in the respective application packaging. That apparmor.d project is a nice starting point indeed.

[Xavier Guillot (valeryan-24)]

Hi, sorry for this newbie question: I see many KDE applications for which a fix is released, great news. Does it mean that every program has to be patched separately, and not directly AppArmor ?

If yes, are Gnome developers aware oh this bug upstream ?…

[John Johansen (jjohansen)]

So the answer is it depends on how they are using unprivileged user namespaces and how they react to them being denied, not every application needs to patched separately.

Generally speaking gnome has been better tested than KDE had because gnome being the Ubuntu default saw a lot more opt in testing in Lunar and Mantic. There is also some differences in how gnome and KDE handle their respective use of their respective browser components that has made KDE current require more direct patching.

We do have some improvements coming down the pipes that will make it easier to have a few some more generic profiles to cover different use patterns. Eg. not all uses of user namespaces set up mappings for the user, some will fallback to a degrade sandbox if an unprivileged user namespace isn't available while others will refuse to function.

Scarlett us doing excellent work within the current limitations. That work will continue to function once the improvements have landed, but it is likely you will see refinements on the current work once those improvements are available.

In general developers are going to have to become aware that user namespaces are going to be more restricted going forward, as its not just Canonical/apparmor pushing on this but SELinux, and likely other LSMs as well in the future. Eg. I have seen BPF LSM using this, and I expect to see some work on the smack side, because the original LSM hook proposals for user namespace mediation came out some work they did.

As for Gnome devs being aware of this bug, yes some are but it has not atm been a major issue for them. Long term I expect both KDE and gnome to take this is a policy issue for the respective LSMs, except when it surfaces code bugs, like some of their library code failing to check if clone/unshare failed, leading to a crash.

Fixing policy to deal with how applications, gnome and KDE use user namespaces will be largely an upstream LSM, or distro problem.

[John Johansen (jjohansen)]

One more addition, the current state of how unconfined deals with unprivileged user namespaces is a temporary limitation. The afore mentioned improvement will allow for more customization at the policy level. The current fixed behavior will be the default.

[Erich Eickmeyer (eeickmeyer)]

John,

The version in the PPA is now older than the version in the repository so no further testing can be done unless the changes in the PPA have now been uploaded (?).

That said, regarding electron apps, it does appear as though the .deb versions of Visual Studio Code and Element Desktop are affected. Granted, those are installed from outside the repository, but I'd contend those are applications a gigantic part of the user base depends on. In fact, for Element, that's something the Ubuntu Community will be relying on in short order.

The only workarounds for these are to install the snap versions or launch with `--no-sandbox`. In Element's case, it's maintained by a third party, so that's the only factor I can see as being problematic.

[Sudip Mukherjee (sudipmuk)]

kgeotag is also affected by #2052491

[John Johansen (jjohansen)]

Erich,

yes the archive version is based on the ppa, with a couple small fixes in the packaging. The ppa is going to get updated based the new archive version + a few more patches.

Do you have some higher priority electron apps that you can point us at. We will look into the Visual Studo and Element Desktop debs. Please keep adding applications to the list. We want to cover as many out of tree applications as we can.

[Scarlett Gately Moore (scarlettmoore)]

Sorry if I missed it the comments. What is the solution for appimages?
Thanks,
Scarlett

[Seth Arnold (seth-arnold)]

Scarlett, Simon and I had discussed preparing a small program that could prepare a wrapper profile: given a path to an appimage, it could emit a small profile to /etc/apparmor.d/ for the file, with the right attachment path and then load the profile.

As I understand our new strategy, it would probably also have to include whatever capabilities that appimage uses as part of setting up the new namespaces -- ideally, it'd be the same capabilities from appimage to appimage.

If there's some reasonable restraints on appimages, like using XDG_SOMETHING for user data storage, that might be nice, too. But that's harder to do.

Thanks

[John Johansen (jjohansen)]

So appimages are interesting. They don't all need a profile. I have run several that are not using user namespaces, or only need to be able to create the user namespace and don't need capabilities so the default unpriviled_userns profile works for them.

It is applications that need privileges within their namespace that are problematic.

Right now no matter what we do, we are stuck with less than satisfactory solutions. The user must physically intervene in some way to make it so the application can run.

I see basically 3 options.

1. Just have the user fix manually, a really bad experience.
2. Seth's suggestion of creating a small script to create a template profile
3. have a default profile already loaded as part of the base set and go with the security label approach. ie. tag the appimage with an apparmor security xattr.

Neither 2, or 3 can determine the set of needed capabilities in advance, but the current approach is to just grant the capabilities (unconfined mode), we will be able to restrict that better in 24.10 but there just isn't time to land the improved capabilities work for 24.04.

Approach 1 could address the capabilities but, that is an awful lot of pain to put on the user.

All approaches will require user to have access to sudo because loading profiles and creating the security xattr are privileged operations.

If aa-notify is installed we could alert the user, and give them directions to a document explaining what to do. This would require some work to seed aa-notify by default (would have to be approved by the different flavors). To make this more amenable we could add a new mode/default filter that only notifies for user namespace denials. This is a small chunk of work that could be achieved in the next two weeks.

The long term goal is to create a behavior similar to what the mac is doing with downloaded applications. The unknown application will create a prompt and the user will need to go to the security center to enable it.

As for restraints on appimages, I wouldn't bother for 24.04, there just isn't time. This side of things will get improvements as well. These template profiles are just a start and are to get fleshed out in the future. Prompting the user for certain accesses etc is coming in the future as well. For now lets just focus on the basics of getting applications to work.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 4.0.0~alpha4-0ubuntu1

---------------
apparmor (4.0.0~alpha4-0ubuntu1) noble; urgency=medium

  [Georgia Garcia]
  * New upstream release.
  * Add unconfined profiles to support the use unprivileged user namespace
    (LP: #2052297, LP: #2046844)
    - d/p/u/add-keybase-unconfined-profile.patch
    - d/p/u/add-more-unconfined-profiles.patch
  * Fix regression tests failures on regex.sh, exec.sh and userns.sh
    - d/p/u/tests-fix-usr-merge-failures-on-exec-and-regex-tests.patch
    - d/p/u/tests-handle-unprivileged_userns-transition-in-usern.patch
  * Drop patches which have now been applied upstream
    - d/p/u/userns-unconfined-profiles.patch
    - d/p/u/tests-fix-userns-setns-opening-pipe-order.patch
    - d/p/u/tests-replace-individual-socket-permissions.patch
    - d/p/u/tests-fix-test-specifying-path-on-attach-disconnected.patch
    - d/p/u/binutils-aa_status.c-quiet-verbose-outputs-when-json.patch
    - d/p/u/oot-unconfined-profiles.patch
  * Refresh patches
    - d/p/d/etc-writable.patch
    - d/p/u/profiles-grant-access-to-systemd-resolved.patch
    - d/p/u/userns-runtime-disable.patch
  * d/apparmor.install
    - install new profiles
      - plasmashell
      - surfshark
      - unprivileged_userns
      - keybase
      - devhelp
      - epiphany
      - evolution
      - opam
    - renamed profiles
      - ch-checkns
      - ch-run
      - crun
      - flatpak
      - linux-sandbox
      - busybox
      - buildah
      - cam
      - ipa_verify
      - lc-compliance
      - libcamerify
      - qcam
      - podman
      - lxc-attach
      - lxc-create
      - lxc-destroy
      - lxc-execute
      - lxc-stop
      - lxc-unshare
      - lxc-usernsexec
      - mmdebstrap
      - vpnns
      - QtWebEngineProcess
      - systemd-coredump
      - rootlesskit
      - rpm
      - runc
      - virtiofsd
      - sbuild
      - sbuild-abort
      - sbuild-adduser
      - sbuild-apt
      - sbuild-checkpackages
      - sbuild-clean
      - sbuild-createchroot
      - sbuild-destroychroot
      - sbuild-distupgrade
      - sbuild-hold
      - sbuild-shell
      - sbuild-unhold
      - sbuild-update
      - sbuild-upgrade
      - slirp4netns
      - stress-ng
      - thunderbird
      - toybox
      - trinity
      - tup
      - userbindmount
      - uwsgi-core
      - vdens
      - chrome
      - msedge
      - brave
      - vivaldi-bin
  * d/apparmor.maintscript
    - add renamed profiles so they are removed on upgrade
  * d/libapache2-mod-apparmor.install
    - remove etc/apparmor.d/local/usr.sbin.apache2, no longer needed

  [John Johansen]
  * debian/rules:
    - don't run debian/put-all-profiles-in-complain-mode.sh on install

  [Alex Murray]
  * debian/apparmor.lintian-overrides:
    - suppress false-positive warning about needing a Depends: on adduser
      for the apparmor binary package

 -- Georgia Garcia <email address hidden> Fri, 02 Feb 2024 16:12:21 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package plasma-welcome - 5.27.10-1ubuntu1

---------------
plasma-welcome (5.27.10-1ubuntu1) noble; urgency=low

  [ Ubuntu Merge-o-Matic ]
  * Merge from Debian unstable. Remaining changes:
    - Kubuntu Vcs and maintainer fields.

  [ Scarlett Moore ]
  * Add apparmor profile to fix userns. Ref: LP: #2046844
  * Release to archive.

plasma-welcome (5.27.10-1) unstable; urgency=medium

  [ Patrick Franz ]
  * New upstream release (5.27.10).

 -- Scarlett Moore <email address hidden> Wed, 21 Feb 2024 04:23:15 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package akonadiconsole - 4:23.08.5-0ubuntu2

---------------
akonadiconsole (4:23.08.5-0ubuntu2) noble; urgency=medium

  * Add apparmor profile to fix userns. Ref: (LP: #2046844)

 -- Scarlett Moore <email address hidden> Sun, 25 Feb 2024 01:25:04 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package kgeotag - 1.5.0-1ubuntu1

---------------
kgeotag (1.5.0-1ubuntu1) noble; urgency=medium

  * Add apparmor profile to fix userns. Ref: (LP: #2046844)

 -- Scarlett Moore <email address hidden> Thu, 15 Feb 2024 00:06:50 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package ghostwriter - 23.08.5+ds-0ubuntu1

---------------
ghostwriter (23.08.5+ds-0ubuntu1) noble; urgency=medium

  * New upstream release (23.08.5)

ghostwriter (23.08.4+ds-0ubuntu2) noble; urgency=medium

  * Add apparmor profile to fix userns. (LP: #2046844)

 -- Scarlett Moore <email address hidden> Thu, 22 Feb 2024 09:31:12 -0700

[Simon Chopin (schopin)]

We had a mitigation for this in glibc but the latest change from simply denying the unshare() call to allowing it but then denying anything requiring capabilities *presumably* broke the glibc test suite again. I'm only basing this from looking at the test logs, as I'm temporarily unable to run autopkgtests locally and am lacking the time to fix it.

2 classes of errors:

2770s FAIL: stdlib/tst-system
2770s original exit status 1
2770s error: test-container.c:1136: could not create a private mount namespace

That one is clearly userns-related, as it's due to a failing mount() call right after unshare()

2770s FAIL: sunrpc/tst-svc_register
2770s original exit status 1
2770s error: xwrite.c:32: write of 12 bytes failed after 0: Operation not permitted
2770s error: 1 test failures

I can't tell for sure what this one is about since this is your basic write() call and I don't have a stack trace at hand, but the EPERM would suggest that it's related.

I think a first fix would be to amend the test script to disable the userns restriction entirely for the duration of the tests (using 'needs-sudo'), while I'll still need to patch the test suite eventually to handle this new failure mode gracefully and simply ignore the tests, akin to https://sourceware.org/pipermail/libc-alpha/2024-February/154754.html

[Erich Eickmeyer (eeickmeyer)]

Geary is seeded in Edubuntu as its main email client, so this is definitely something we'd like fixed.

[Erich Eickmeyer (eeickmeyer)]

Also would like to note that tuxedo-control-center, a third-party Electron app for Tuxedo Computers, is affected by this.

[Scarlett Gately Moore (scarlettmoore)]

plasma-desktop and kdeplasma-addons are in the main apparmor package and fixed. Is it ok to make those are fix-released?

[cipricus (cipricus)]

I've experienced this (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2056190) in Kubuntu 24.04:

- related to Firefox and Firefox-based browsers (Waterfox, Librewolf, Midori, Floorp, Mullvad) installed from deb, running locally ("portable"), or as appimage, while flatpak and snap versions are NOT affected (as far as I've been able to test, given that only Firefox seems available as snap)

- related to kernel version 6.8.0 in 24.04, while 6.5 was not affected

[Alexander Browne (elcste)]

I am seeing this with the (relatively new) Mozilla-provided Firefox deb package (https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions).

[John Johansen (jjohansen)]

This is part of the alpha4 release in noble

[John Johansen (jjohansen)]

This is part of the apparmor alpha4 release in noble

[John Johansen (jjohansen)]

@scarlet I think it is fair to mark these as Fixed released as they are part of apparmor-alpha4 that is in noble.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Xavier Guillot (valeryan-24)]

Yes, since today's updates, Firefox Nightly 125.0a1 from Mozilla repositery which worked very fined until now, stopped : program still well starts, but every tab gets a crash error and doesn't laod the page (even the start about:blank one)…

[Xavier Guillot (valeryan-24)]

I reported the bug upstream for Firefox - if you have a Bugzilla account on Mozilla and are affected, you could confirm it please :

https://bugzilla.mozilla.org/show_bug.cgi?id=1884347

[Guy Schlosser (guyster)]

I am seeing this also, as of updating all packages, about fifteen minutes ago. Is there a definite fix released? This doesn't mean we have to resort to using firefox from snap, right?

[Guy Schlosser (guyster)]

I have read in a couple other pages that I can edit /etc/apparmor.d/firefox. Since I'm using version 124 beta 9, and my firefox is installed in /opt/firefox, do I just adjust the path in that file to make it work? Thanks much in advance for the help.

[Fred (eldmannen+launchpad)]

A workaround is to set the environment variable MOZ_ASSUME_USER_NS=0.

You can run it as:
env MOZ_ASSUME_USER_NS=0 /home/bob/Downloads/firefox/firefox --name=firefox-nightly %u

[Guy Schlosser (guyster)]

Before I saw your post about the environment variable, I edited the profile in /etc/apparmor.d/firefox to reflect /opt/firefox. If I launch from a mate desktop icon, or from the menu, all is well. If I click on a link, from say an email, I get the tab crashed bug again. Is there a way to work around this? I'm using Thunderbird, installed the same way, for my email.

[Xavier Guillot (valeryan-24)]

Fix released for Firefox (Nightly) 125.

Since a few days, I can't launch Gpodder (podcast program) anymore, is it also related to this bug or is it something different ?

"[gpodder.log] ERROR: Uncaught exception: Traceback (most recent call last):
  File "/usr/bin/gpodder", line 181, in <module>
    main()
  File "/usr/bin/gpodder", line 173, in main
    from gpodder.gtkui import app
  File "/usr/lib/python3/dist-packages/gpodder/gtkui/app.py", line 31, in <module>
    from gpodder import core, util
  File "/usr/lib/python3/dist-packages/gpodder/core.py", line 25, in <module>
    from gpodder import config, dbsqlite, extensions, model, util
  File "/usr/lib/python3/dist-packages/gpodder/extensions.py", line 34, in <module>
    import imp
ModuleNotFoundError: No module named 'imp'

Traceback (most recent call last):
  File "/usr/bin/gpodder", line 181, in <module>
    main()
  File "/usr/bin/gpodder", line 173, in main
    from gpodder.gtkui import app
  File "/usr/lib/python3/dist-packages/gpodder/gtkui/app.py", line 31, in <module>
    from gpodder import core, util
  File "/usr/lib/python3/dist-packages/gpodder/core.py", line 25, in <module>
    from gpodder import config, dbsqlite, extensions, model, util
  File "/usr/lib/python3/dist-packages/gpodder/extensions.py", line 34, in <module>
    import imp
ModuleNotFoundError: No module named 'imp'"

[John Johansen (jjohansen)]

@valeryan-24 ModuleNotFoundError: No module named 'imp'" says that your Gpodder issue is not related to this bug. You are missing a dependency the 'imp' module. If Gpodder is packaged it will need to add that as part of its install dependencies.

[Georgia Garcia (georgiag)]

Erich Eickmeyer, I don't have a Tuxedo Computer to test, so could you please check if the following profile works for you?

$ echo "# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile tuxedo-control-center /opt/tuxedo-control-center/tuxedo-control-center flags=(unconfined) {
  userns,

  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/tuxedo-control-center>
}" | sudo tee /etc/apparmor.d/tuxedo-control-center

$ sudo apparmor_parser /etc/apparmor.d/tuxedo-control-center

and restart tuxedo-control-center.

[John Johansen (jjohansen)]

@guyster, @eldmannen+launchpad, @valeryan-24

Firefox dailies now have a work around, by detecting and disabling the user namespace. The proper fix that should allow firefox to still use the user namespace for its sandbox will land in Beta3, landing early next week.

[John Johansen (jjohansen)]

@eeickmeyer geary should be fixed in Beta3

[John Johansen (jjohansen)]

@sudipmuk loupe should be fixed in Beta3

[John Johansen (jjohansen)]

I have tried freecad and unprivileged user namespace restrictions are not the problem. freecad snap works, freecad ppa does not have a noble build yet but the mantic build can be made to work.

freecad daily appimage: works
freecad appimage: stable fails with mesa or qt errors depending on how/where it is started. Below is a paste of the error
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load driver: zink
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
failed to load driver: swrast

[John Johansen (jjohansen)]

supercollider will work on current noble. Since it is using QTWebEngine it has a graceful fallback when capabilities within the user namespace are denied.

supercollider will have a profile and be fixed in Beta3, so it doesn't even have to do the fallback.

[John Johansen (jjohansen)]

I have tested gnome-packagekit and it never trigger unprivileged user namespace mediation. Can you please provide more information on how you triggered it.

[John Johansen (jjohansen)]

we will be fixed in Beta3

[John Johansen (jjohansen)]

Will be fixed in Beta3

[John Johansen (jjohansen)]

sorry this won't be fixed in Beta3 that note was for goldendict

[John Johansen (jjohansen)]

this will be fixed in Beta

[Xavier Guillot (valeryan-24)]

Hi, for Gnome-packagekit it's related to this behavior :

https://bugs.launchpad.net/ubuntu/+source/gnome-packagekit/+bug/2046843

I run Ubuntu development branch 24.04 and I have a problem with Gnome PackageKit 43.0-2 : application launches well, but if I write a program / package name in the search field and click on"Enter", it crashes and closes :

$ gpk-application

(gpk-application:6130): PackageKit-CRITICAL **: 10:51:02.410: pk_client_generic_finish: assertion 'G_IS_TASK (res)' failed
Erreur de segmentation (core dumped)

It stills occurs on my computer…

[Erich Eickmeyer (eeickmeyer)]

Georgia,

RE: tuxedo-control-center

That works perfectly.

[John Johansen (jjohansen)]

hi @vvaleryan-24,

I have been able to replicate the crash you are seeing but it is not do to the user namespace restriction. The restrictions logging does not happen, and I can put it in an unconfined profile and it still doesn't help. From dmesg I find the following segfault

[79854.520976] gpk-application[19250]: segfault at 8 ip 00005930eec2dba8 sp 00007fff471b6b70 error 4 in gpk-application[5930eec24000+d000] likely on CPU 1 (core 0, socket 1)
[79854.520985] Code: 85 ff 0f 85 72 fd ff ff e9 72 fd ff ff 0f 1f 44 00 00 48 8b 44 24 30 48 8d 15 37 46 00 00 be 10 00 00 00 48 8d 3d c2 34 00 00 <48> 8b 48 08 31 c0 e8 6d 79 ff ff c7 43 04 00 00 00 00 48 8b 7b 50

my recommendation is we move debugging over of this to the other bug.

[John Johansen (jjohansen)]

@kc2bez:

there are no updated deb packages in the ppa for kiwix.
the kiwix appimage worked for me.
kiwix flatpak worked for me.

I am not sure what you were seeing. But I we are going to need more information.

[John Johansen (jjohansen)]

@kc2bez: notepadqq should be fixed in beta3

[John Johansen (jjohansen)]

@kc2bez: pageedit should be fixed in beta3

[John Johansen (jjohansen)]

@kc2bez: I have been able to verify that privacybrowser is not working. However it is not due to the apparmor user namespace restrictions.

I get the following segfault out of dmesg
[ 1591.466016] privacybrowser[7743]: segfault at 8 ip 000070bb4dd11ccc sp 00007ffd5c6587e0 error 4 in libQt5Core.so.5.15.12[70bb4da8e000+335000] likely on CPU 0 (core 0, socket 0)
[ 1591.466026] Code: ff ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 81 ec 98 00 00 00 48 89 55 80 <48> 8b 5f 08 89 b5 7c ff ff ff 64 48 8b 04 25 28 00 00 00 48 89 45

I recommend opining a separate bug to track the issue.

[John Johansen (jjohansen)]

@kc2bez: qmapshack should be fixed in beta3

[John Johansen (jjohansen)]

@arraybolt3: qutebrowser should be fixed in beta3

[ajgreeny (ajg-charlbury)]

I have seen the problem with firefox tabs crashing in the .deb installation and when running direct from the downloaded .tar.bz from Mozilla.
Firefox opens but tabs show error saying "Tab crashed"
This has forced me to use the snap version which works fine though I prefer not to use snaps at all as I dislike the lack of control of them and the restrictions on use that they create

[John Johansen (jjohansen)]

@ajg-charlbury: yes, firefox we are well aware of the problem, the firefox profile has been tweaked for beta3 (landing this week) so that it should work with the new deb.

[ajgreeny (ajg-charlbury)]

I have just tried running firefox from the firefox-nightly download and all runs well using that version
125.0a1 (2024-03-17) (64-bit).

I assume the beta3 you speak of is the new version of apparmor; is that the same version as the current apparmor-proposed version?

[John Johansen (jjohansen)]

@ajg-charlbury: no apparmor beta3 has not landed in proposed yet, we are working on the upload now. firefox separately have added a bug fix that will detect when the user namespace/capabilities are denied and fallback without crashing but it disables the full sandbox.

the apparmor-beta3 fix should enable firefox to function with the full sandbox.

[corrado venturini (corradoventu)]

loupe problem solved with apparmor 4.0.0-beta3-0ubuntu2
https://bugs.launchpad.net/ubuntu/+source/loupe/+bug/2054142

[Coeur Noir (coeur-noir)]

Ubuntu 24.04 installed today.

Firefox autonomous archive downloaded from https://www.mozilla.org/fr/firefox/all/#product-desktop-release

And « ooops… » in any tab,

terminal says :

[Parent 5931, IPC I/O Parent] WARNING: process 6020 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6026 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6036 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6084 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6099 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6110 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6119 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6128 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6143 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6147 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265
[Parent 5931, IPC I/O Parent] WARNING: process 6150 exited on signal 11: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:265

…firefox as a snap looks to run fine but I have many bwrap processes that use 100% cpu to the point of over-heating.
Is it related ?
See picture of monitor → https://i.ibb.co/BZCfNjJ/2404-bwrap.png

[John Johansen (jjohansen)]

@coeur-noir:

Are you installing firefox to /opt/ as recommended or using it local in your user account?

as for bwarp, maybe it is known to be problematic. It is allowed to run and to create a user namespace but it is denied all capabilities within the namespace.

Can you run
  sudo dmesg | grep apparmor

and add the information here.

[John Johansen (jjohansen)]

We have an update of the firefox profile coming that supports the /opt/firefox/firefox location used as the default install for the firefox downloaded directly from mozilla.org

If you are running firefox out of your home directory, that will not be directly supported and you will need to chose to do one of the following to fix the issue.

1. The recommended way is updating the firefox profile in /etc/apparmor.d/firefox by adding the location you have firefox installed, and then reloading the profile with sudo apparmor_parser -r /etc/apparmor.d/firefox.

2. You can disable user namespaces, this will keep firefox from trying to use them as part of ts sandbox https://lwn.net/Articles/673597/

3. the least recommended way to fix this is you can disable the finer grained user namespace restrictions as outlined in https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces

[fossfreedom (fossfreedom)]

Hi - ok - very long thread so not quite sure how best to resolve.

I note bubblewrap is marked as confirmed but no resolution.

For budgie-control-center - backgrounds - Add Picture I found that the gnome-desktop library libgnome-desktop-3-20 is calling bwrap and that this was failing due to permissions.

I worked around this via

```
cat /etc/apparmor.d/bwrap
# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,

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

Can this be added to apparmor please?

[Aaron Rainbolt (arraybolt3)]

I believe bwrap was ignored intentionally, as the point of the apparmor change was to prevent arbitrary apps from making unprivileged user namespaces with capabilities. Allowing Bubblewrap to do so would provide a loophole. Same reason `unshare` isn't allowed to make unprivileged namespaces with capabilities.

Perhaps something about libgnome-desktop is incorrectly assuming it needs capabilities that it doesn't actually need? Or is the ability to make unprivileged user namespaces with no capabilities failing somehow?

[John Johansen (jjohansen)]

@arraybolt3 is correct. Both unshare and bwrap will not get a unconfined profile, as that allows for an arbitrary by-pass of the restriction. There is a potential solution in the works that will allow for bwrap and unshare to function as long as the child task does not require permissions but at this point there are still some issues with it that are being debugged.

[John Johansen (jjohansen)]

@arraybolt3: Answer to your question. bwrap requires capabilities within the user namespace. unshare is a little more forgiving in that what it requires depends on the options passed but most of the options also require capabilities within the user namespace.

The potential solution I mention is comment #91 is to define a profile for bwrap that allows it capabilities within the namespace but does not allow its children capabilities within the namespace, so that bwrap and unshare can not just launch an application to by-pass the restriction. This seems to work well for unshare but there are cases where bwrap is failing in unexpected ways (which is still being debugged).

At this late stage the plan is to try to get a fix for bwrap in but if necessary to file an SRU if necessary for the bwrap fix. So yes this is being worked on and even if the fix isn't present on day one we do plan to get it fixed.

[Archisman Panigrahi (apandada1)]

https://gitlab.com/apparmor/apparmor/-/merge_requests/1209

[Archisman Panigrahi (apandada1)]

https://gitlab.com/apparmor/apparmor/-/merge_requests/1212

[Archisman Panigrahi (apandada1)]

Can we manually add support for Balena Etcher, just like VS Code? Etcher is used by hundreds of thousands of users.