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

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

[Mateusz Stachowski (stachowski-mateusz)]

I had no problem running Balena Etcher on Ubuntu 24.04 LTS.

Do you have the latest version of Etcher?

1.19.16

https://github.com/balena-io/etcher/blob/master/CHANGELOG.md

[John Johansen (jjohansen)]

The Wike fix is coming in the next SRU.

[John Johansen (jjohansen)]

Balena Etcher 1.18 dpkg won't install on 24.04 due to dependency issues, 1.19.16 installs fine and runs, but in a degraded sandbox mode. So adding a profile for it would be beneficial

The appimage version of Belena Etcher unfortunately fails to run. We can not provide a default profile for the appimage unless it the user moves it to the default deb install location (ie. installs it to the system, instead of running it from their home dir). Users are free to add their own confinement profiles for appimages. Directions are in https://discourse.ubuntu.com/t/noble-numbat-release-
notes/39890#unprivileged-user-namespace-restrictions-15

[Douglas Lucas (u-dal)]

I seem to have the same apparmor problem with Chrome under Lubuntu 24.04. From "$ journalctl | grep apparmor | grep chrome" I got info="Userns create restricted - failed to find unprivileged_userns profile" (among other things). And it's been reproduced by another as the following relates.

EDIT: This is all in a live boot environment.

Can anyone help? Much more detail below. And you can email me: <email address hidden>.

Prior Lubuntu versions, I wget'd the latest Chrome deb from Google and installed it via sudo dpkg -i. Usually it worked quite well. Now with Lubuntu 24.04, I downloaded the latest Chrome deb the same way on Apr. 28, 2024, but Chrome's not working.

If I run /usr/bin/google-chrome or /usr/bin/google-chrome-stable:

```
$ google-chrome
[55151:55151:0428/224255.271437:FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)
Trace/breakpoint trap (core dumped)
```

or

```
$ google-chrome-stable
[55166:55166:0428/224300.689874:FATAL:credentials.cc(127)] Check failed: . : Permission denied (13)
Trace/breakpoint trap (core dumped)
```

Meanwhile, $ sudo netstat -antvp shows active connections to multiple IPs associated with Google, presumably because I tried multiple times to get Chrome to launch.

Then,

```
$ ls /etc/apparmor.d
1password firefox lxc-stop rootlesskit scide usr.bin.redshift
Discord flatpak lxc-unshare rpm signal-desktop usr.bin.tcpdump
MongoDB_Compass force-complain lxc-usernsexec rssguard slack usr.lib.libreoffice.program.oosplash
QtWebEngineProcess geary mmdebstrap rsyslog.d slirp4netns usr.lib.libreoffice.program.senddoc
abi github-desktop msedge runc steam usr.lib.libreoffice.program.soffice.bin
abstractions goldendict nautilus sbuild stress-ng usr.lib.libreoffice.program.xpdfimport
brave ipa_verify notepadqq sbuild-abort surfshark usr.lib.snapd.snap-confine.real
buildah kchmviewer nvidia_modprobe sbuild-adduser systemd-coredump usr.sbin.cups-browsed
busybox keybase obsidian sbuild-apt thunderbird usr.sbin.cupsd
cam lc-compliance opam sbuild-checkpackages toybox usr.sbin.rsyslogd
ch-checkns libcamerify opera sbuild-clean trinity uwsgi-core
ch-run linux-sandbox pageedit sbuild-createchroot tunables vdens
chrome local plasmashell sbuild-destroychroot tup virtiofsd
code loupe podman sbuild-distupgrade tuxedo-control-center vivaldi-bin
crun lsb_release polypane sbuild-hold ubuntu_pro_apt_news vpnns
devhelp lxc-attach privacybrowser sbuild-shell unix-chkpwd wpcom
element-desktop lxc-create qcam ...

[John Johansen (jjohansen)]

@u-dal:

This sounds like the apparmor policy is not being loaded can you please provide the output of

```
sudo aa-status
```

and

```
sudo systemctl status apparmor
```

[Douglas Lucas (u-dal)]

@jjohansen:

```
$ sudo aa-status
apparmor module is loaded.
56 profiles are loaded.
54 profiles are in enforce mode.
   /snap/snapd/21465/usr/lib/snapd/snap-confine
   /snap/snapd/21465/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   libreoffice-senddocists=!/rofs/etc/apparmor.d).
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   rsyslogd
   snap-update-ns.chromium
   snap-update-ns.cups
   snap-update-ns.firefox
   snap-update-ns.firmware-updater
   snap-update-ns.thunderbird
   snap.chromium.chromedriver
   snap.chromium.chromium
   snap.chromium.hook.configure
   snap.cups.accept
   snap.cups.cancel
   snap.cups.cups-browsed
   snap.cups.cupsaccept
   snap.cups.cupsctl
   snap.cups.cupsd
   snap.cups.cupsdisable
   snap.cups.cupsenable
   snap.cups.cupsfilter
   snap.cups.cupsreject
   snap.cups.cupstestppd
   snap.cups.driverless
   snap.cups.gs
   snap.cups.ippeveprinter
   snap.cups.ippfind
   snap.cups.ipptool
   snap.cups.lp
   snap.cups.lpadmin
   snap.cups.lpc
   snap.cups.lpinfo
   snap.cups.lpoptions
   snap.cups.lpq
   snap.cups.lpr
   snap.cups.lprm
   snap.cups.lpstat
   snap.cups.reject
   snap.firefox.firefox
   snap.firefox.geckodriver
   snap.firefox.hook.configure
   snap.firefox.hook.connect-plug-host-hunspell
   snap.firefox.hook.disconnect-plug-host-hunspell
   snap.firefox.hook.post-refresh
   snap.firmware-updater.firmware-notifier
   snap.firmware-updater.firmware-updater
   snap.firmware-updater.firmware-updater-app
   snap.firmware-updater.hook.configure
   snap.thunderbird.hook.configure
   snap.thunderbird.thunderbird
2 profiles are in complain mode.
   libreoffice-oosplash
   libreoffice-soffice
0 profiles are in prompt mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
31 processes have profiles defined.
31 processes are in enforce mode.
   /usr/sbin/rsyslogd (1472) rsyslogd
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77339) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome_crashpad_handler (77395) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome_crashpad_handler (77397) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77401) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77402) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77404) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77433) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77441) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (77443) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (78308) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (78968) snap.chromium.chromium
   /snap/chromium/2828/usr/lib/chromium-browser/chrome (79729) snap.chromium.chromium
   /usr/bin/dash (18605) snap.cups.cups-browsed
   /usr/bin/dash (18912) snap.cups.cups-browsed
   /usr/bin/sleep (92417) snap.cups.cups-browsed
   /usr/bin/das...

[John Johansen (jjohansen)]

@u-dal:
are you running in a live cd environment? Something odd is happening on your system, with some profiles loaded and systemctl reporting ConditionPathExists=!/rofs/etc/apparmor.d

[Douglas Lucas (u-dal)]

@u-jjohansen:

Yes, live environment only. Sorry, I thought I'd included that in my first comment but now I see that I neglected to do so. I added an EDIT: to my first comment to make it clear.

[Douglas Lucas (u-dal)]

@u-jjohansen:

Also, I'm having this Thunderbird problem going on simultaneously -- https://forum.snapcraft.io/t/unexplained-thunderbird-already-running-but-is-not-responding-message/39990 -- which might be related to the issues from my Chrome comments?

[John Johansen (jjohansen)]

@u-dal:

the problem with firefox (it has a snap profile and is allowed access to user namespaces) is different than with chrome (no profile loaded), but still might be apparmor related. Can you look in dmesg for apparmor denials

```
  sudo dmesg | grep DENIED
```

[Douglas Lucas (u-dal)]

@u-jjohansen:

```
$ sudo dmesg | grep DENIED
[ 20.729222] audit: type=1400 audit(1714359674.872:42): apparmor="DENIED" operation="open" class="file" profile="snap-update-ns.firefox" name="/usr/local/share/" pid=2002 comm="6" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 20.743227] audit: type=1400 audit(1714359674.886:43): apparmor="DENIED" operation="open" class="file" profile="snap-update-ns.firefox" name="/var/lib/" pid=2002 comm="6" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 20.743368] audit: type=1400 audit(1714359674.886:44): apparmor="DENIED" operation="open" class="file" profile="snap-update-ns.firefox" name="/var/lib/" pid=2002 comm="6" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 20.743817] audit: type=1400 audit(1714359674.886:45): apparmor="DENIED" operation="open" class="file" profile="snap-update-ns.firefox" name="/var/lib/" pid=2002 comm="6" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 20.743821] audit: type=1400 audit(1714359674.886:46): apparmor="DENIED" operation="open" class="file" profile="snap-update-ns.firefox" name="/var/lib/" pid=2002 comm="6" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 496.181770] audit: type=1400 audit(1714360150.324:49): apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 profile="unconfined" name="ubuntu_pro_apt_news" pid=2609 comm="(python3)"
[ 526.667987] audit: type=1400 audit(1714360181.273:50): apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 profile="unconfined" name="ubuntu_pro_apt_news" pid=2767 comm="(python3)"
[ 554.736942] audit: type=1400 audit(1714360209.342:51): apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 profile="unconfined" name="ubuntu_pro_apt_news" pid=3216 comm="(python3)"
[ 2204.153512] audit: type=1400 audit(1714361858.768:60): apparmor="DENIED" operation="capable" class="cap" profile="/usr/lib/snapd/snap-confine" pid=8056 comm="snap-confine" capability=12 capname="net_admin"
[ 2204.153520] audit: type=1400 audit(1714361858.768:61): apparmor="DENIED" operation="capable" class="cap" profile="/usr/lib/snapd/snap-confine" pid=8056 comm="snap-confine" capability=38 capname="perfmon"
[ 2205.965365] audit: type=1107 audit(1714361860.578:62): pid=1389 uid=101 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/login1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.2" pid=8056 label="snap.firefox.firefox" peer_pid=1382 peer_label="unconfined"
[ 2206.032369] audit: type=1107 audit(1714361860.647:63): pid=1389 uid=101 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/timedate1" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.83" pid=8056 label="snap.firefox.firefox" peer_pid=8746 peer_label="unconfined"
[ 2206.032740] audit: type=1107 audit(1714361860.647:64): pid=1389 uid=101 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call" bus="sys...

[John Johansen (jjohansen)]

For the thunderbird issue I have created https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2064363

[Julian Andres Klode (juliank)]

bubblewrap should be won't fix per comment #91 from jjohansen

[Zed (zgraft)]

Probably not in scope but the Tor Browser also fails to start properly: https://forum.torproject.org/t/ubuntu-24-04-daily-and-tor-tabs-crashing-immediately/11822/7. I can see why Ubuntu might not want to allow such programs but, a universal distribution should be cognizant that some of its users value privacy and that default apparmor profiles make it problematic for such users to maintain their privacy.

[Aaron Rainbolt (arraybolt3)]

The Tor Browser is actually installable on Ubuntu, and we have
privacy-conscious folks here who are Ubuntu Developers. We just were
absolutely slammed in more ways than we imagined would happen this
cycle and things slipped through the cracks. This is probably one of
them.

You can follow the instructions for adding an AppArmor profile to work
around the issue (they're up somewhere in the comments, near the top).
Also, where is your Tor Browser binary on your filesystem? We may be
able to add a profile specifically for it.

On Mon, May 6, 2024 at 2:55 PM Zed <email address hidden> wrote:
>
> Probably not in scope but the Tor Browser also fails to start properly:
> https://forum.torproject.org/t/ubuntu-24-04-daily-and-tor-tabs-crashing-
> immediately/11822/7. I can see why Ubuntu might not want to allow such
> programs but, a universal distribution should be cognizant that some of
> its users value privacy and that default apparmor profiles make it
> problematic for such users to maintain their privacy.
>
> --
> You received this bug notification because you are a member of Lubuntu
> Packages Team, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/2046844
>
> Title:
> AppArmor user namespace creation restrictions cause many applications
> to crash with SIGTRAP
>
> Status in AppArmor:
> New
> Status in Wike:
> New
> Status in akonadiconsole package in Ubuntu:
> Fix Released
> Status in akregator package in Ubuntu:
> Fix Released
> Status in angelfish package in Ubuntu:
> Fix Released
> Status in apparmor package in Ubuntu:
> Fix Released
> Status in bubblewrap package in Ubuntu:
> Won't Fix
> Status in cantor package in Ubuntu:
> Fix Released
> Status in devhelp package in Ubuntu:
> Fix Released
> Status in digikam package in Ubuntu:
> Fix Released
> Status in epiphany-browser package in Ubuntu:
> Fix Released
> Status in evolution package in Ubuntu:
> Fix Released
> Status in falkon package in Ubuntu:
> Fix Released
> Status in firefox package in Ubuntu:
> Confirmed
> Status in foliate package in Ubuntu:
> Fix Committed
> Status in freecad package in Ubuntu:
> Invalid
> Status in geary package in Ubuntu:
> Fix Released
> Status in ghostwriter package in Ubuntu:
> Fix Released
> Status in gnome-packagekit package in Ubuntu:
> Invalid
> Status in goldendict-webengine package in Ubuntu:
> Fix Released
> Status in guix package in Ubuntu:
> New
> Status in kalgebra package in Ubuntu:
> Fix Released
> Status in kchmviewer package in Ubuntu:
> Fix Released
> Status in kdeplasma-addons package in Ubuntu:
> Fix Released
> Status in kgeotag package in Ubuntu:
> Fix Released
> Status in kiwix package in Ubuntu:
> Incomplete
> Status in kmail package in Ubuntu:
> Fix Released
> Status in konqueror package in Ubuntu:
> Fix Released
> Status in kontact package in Ubuntu:
> Fix Released
> Status in loupe package in Ubuntu:
> Fix Released
> Status in marble package in Ubuntu:
> Fix Released
> Status in notepadqq package in Ubuntu:
> Fix Released
> Status in opam package in Ubuntu:
> Fix Released
> Status in pageedit package in Ubuntu:
> Fix Released
> Status ...

[Jorge LaviLa (jorge-lavila)]

Hello,

Pardon my ignorance, but I ship applications with my own build of bubblewrap to run in a sandboxed manner. bwrap's pivot_root allows my application to work across several distros without worrying about issues with missing or incompatible libraries; it also makes possible to run the same binary on both musl and glibc systems.

Does this mean that this will never work on ubuntu again even after the proposed fix (since I do not use the system provided /usr/bin/bwrap binary)?

[Aaron Rainbolt (arraybolt3)]

Unless your app and Bubblewrap can both work without any capabilities in an unprivileged user namespace, things will probably go south. You should probably be installing an AppArmor profile for your app that allows you to use unprivileged user namespaces normally again, as described in Comment 5 (https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844/comments/5). You can look at `/etc/apparmor.d/chrome` as an example profile, and make your profile similar. This will require that your build of Bubblewrap be installed into a static location on the filesystem - if you're depending on Bubblewrap working no matter where the binary is on the filesystem (for instance, if your app is portable and is shipped as a .tar.gz that people unpack into their home dir and then use), you'll need to turn off the user namespace restrictions entirely during the install process, as described in the Ubuntu 24.04 release notes (https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890):

* Disable this restriction using a persistent setting by adding a new file (/etc/sysctl.d/60-apparmor-namespace.conf) with the following contents:

  kernel.apparmor_restrict_unprivileged_userns=0

  Reboot. This is similar to the previous behaviour, but it does not mitigate against kernel exploits that abuse the unprivileged user namespaces feature.

Try to avoid using the "disable unprivileged user namespace restriction" solution if at all possible.

[Aaron Rainbolt (arraybolt3)]

Also note that even the system's build of Bubblewrap is not granted the ability to bypass user namespace restrictions as that would allow the restrictions to be bypassed by any application. Doing this to your own build of Bubblewrap will pose the same security issue. If you can avoid doing things the way you're doing, that would be best, otherwise just turning off the restriction or granting your build of Bubblewrap an exception at install time is probably the best you can do.

[Jorge LaviLa (jorge-lavila)]

Thanks for the reply!

My use case is this one 'shipped as a .tar.gz that people unpack into their home dir and then use'. To me it seems counter-intuitive to force applications to run un-sanboxed for added security; both the solutions proposed (with the application profile and to turn off the user namespace restrictions) would require root privileges, which I currently do not require users to have to be able to run my application. Does Ubuntu have plans for an alternative to bubblewrap sandboxing? Blocking kernel features because they might be exploited seems really extreme.

[John Johansen (jjohansen)]

@jorge-lavila,

Its not a theoretical case, they have been used by multiple exploits every year (including this one) since landing in the kernel. Ubuntu is not the only ones looking at restricting them. SELinux has also picked up the ability but they haven't really rolled it out in policy, there are also discussions in other security forms (eg. the OSS security list) about how to disable them better than the giant sysctl that turns them off for everything.

The apparmor solution allows doing it on a per application basis. Yes it deliberately requires a privileged operation, otherwise the restriction could be trivially by-passed by exploit code. We know the experience is not user friendly atm, and are working on improving it. Improving both the flexibility on what is mediated on how the user can by-pass/disable the restriction. On the GUI side the end goal is something similar to what you get on MacOS where the user gets notified, and has to go to the security center to enable running an untrusted application.

There is in fact a profile coming for bwrap, and unshare, but not the unconfined profile that is being generically used to disable the restriction. The profile will restrict certain modes of operation, and prevent applications launch by it from having privilege within the user namespace. It will open the ubuntu shipped versions up for regular users again for many of its use cases.

Unfortunately untrusted code, which is the case of code downloaded into the home dir, will require a privileged operation to be able to use user namespaces. That could be the use of sudo when using the application, or creating a profile for the application, which then allows the user to subsequently use the application without a privileged operation.

[John Johansen (jjohansen)]

@zgraft:
I have added a tor item, a profile will land in an update.

[Jorge LaviLa (jorge-lavila)]

Thanks for the detailed reply @jjohansen,

Do you think it would be feasible to spawn a pop-up that says something like "This application uses namespaces which is considered vulnerable to exploits, are you sure you want to continue?" and ask for the password to allow the application to run. This would resolve the issue while still allowing portable applications to run properly. This could be achieved for example providing a tool to ask apparmor for permissions. From my side I can just detect if apparmor is used and ask apparmor to grant access to namespaces, in term, apparmor would spawn a pop-up for the user saying that my application is requesting this permission.

[John Johansen (jjohansen)]

@jorge-lavila:

technically possible yes. I want to be careful with what I promise here, as the user experience is not my area. With that said we are currently looking at using aa-notify as a bridge to improve the user experience. We would install it with a filter to only fire a notification for the user namespace denial/transition. That notification will show in your desktops notification area with a button/click action that will launch a user prompt. There will have to be an SRU to add some of the new functionality, but we can make it available before the SRU via a ppa for those who want to test.

I will make sure to update this bug when we have this ready for testing.

[Pirouette Cacahuète (lissyx)]

I have just upgraded to 24.04 from 23.10 and I'd like to emphasize that for the Firefox case, the comments on that thread mentions "AppArmor should fix it with beta3" is inaccurate and incomplete: it only partially fixes the issue since it only covers packaged versions.

Anybody relying on the tarball should have something similar (assuming you install in $HOME/bin/firefox)
> $ cat /etc/apparmor.d/firefox-bin
> # 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 firefox /home/XXX/bin/firefox/firefox flags=(unconfined) {
> userns,
>
> # Site-specific additions and overrides. See local/README for details.
> include if exists <local/firefox>
> }

[John Johansen (jjohansen)]

The AppArmor profile covers the packaged version and the standard privileged install location. You are correct that it does not cover running firefox from an unprivileged user writable location like $HOME.

For unprivileged user writable locations like $HOME/bin/ the user has to deliberately make a privileged action like installing a profile for the location of the application. This applies to the appimage version run out of the users $HOME as well.

[Pirouette Cacahuète (lissyx)]

Yep, this is fine. I just wanted to make it clear for others, because one of the comment above might be misleading and even though I know the area of the code impacted by userns, I was actually thinking you got a fix landed on AppArmor side to avoid the need for a dedicated profile.

AppImage being impacted might also be good to report to those upstream?

[John Johansen (jjohansen)]

Yes for the appimages that are affected they should be reported upstream. There are some things that upstream can do to make appimages work under the restriction, ideally they would do it dynamically based on whether the user namespace is available than just based on distro which is the quick fix some have done.

[Pirouette Cacahuète (lissyx)]

I am also just wondering how we can effectively work on sandbox-related code on 24.04 ; does it means any developper (and potentially CI) will have to setup its AppArmor profile **also** matching the builds to have proper userns ? The way it is currently handled, I dont see any other way around, but it also means it needs to be done for any objdir we work on ?