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)]

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 ?

[Launchpad Janitor (janitor)]

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

[Marcos Alano (mhalano)]

I'm having a similar problem, but I don't know if it's related: I'm using Ubuntu 24.04, Firefox from Mozilla PPA (so no Snap), and I get this error in the journalctl -b:
mai 23 15:39:24 glados firefox.desktop[8963]: [Parent 8963, IPC I/O Parent] WARNING: process 47676 is a zombie: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/process_util_posix.cc:245
It freezes all my session, not just the Firefox, and I need to long press the power button to turn off the machine.

[John Johansen (jjohansen)]

@mhalano:

can you check your logs for apparmor denial messages?

sudo dmesg | grep DENIED

or

journalctl -g apparmor

[Marcos Alano (mhalano)]

Trying to get details. I just found one folk on the Internet with the exactly same error as me: https://forums.debian.net/viewtopic.php?t=159229

[Pirouette Cacahuète (lissyx)]

John, I think it's worth mentionning this is also breaking usage of MozRegression tool. I think it requires a profile allowing any firefox binary under /tmp for unblocking ...

[Marcos Alano (mhalano)]

I wasn't able to get any error related with Firefox and AppArmor. Plenty of errors related with AppArmor and some snaps, but I think it's expected.

[Steve Langasek (vorlon)]

The bug task for bubblewrap was marked 'wontfix' on the basis that John said it will not get an unconfined profile. But this is wrong; that is saying only that a particular solution is rejected, not that we will not be making changes to this package.

bubblewrap is part of the desktop and having it not work is a significant release regression, to the point where people are now proposing SRUs to work around this breakage by bypassing the security benefits of bubblewrap's sandboxing (LP: #2065708). This needs to be addressed.

[Chris Halse Rogers (raof)]

An upload of apparmor to noble-proposed has been rejected from the upload queue for the following reason: "dpkg-source: warning: diff 'apparmor-4.0.1/debian/patches/ubuntu/profiles-fix-wike-profile-location-to-apparmor.d.patch' doesn't contain any patch - you can't rename files in a diff!".

[Chris Halse Rogers (raof)]

Hello Xavier, or anyone else affected,

Accepted apparmor into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/4.0.1-0ubuntu0.24.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[John Johansen (jjohansen)]

A profile for bwrap is in the 4.0.1 SRU

[Georgia Garcia (georgiag)]

Verification done as part of Bug 2064672

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 4.0.1-0ubuntu0.24.04.2

---------------
apparmor (4.0.1-0ubuntu0.24.04.2) noble; urgency=medium

  [Georgia Garcia]
  * New upstream release. (LP: #2064672)
  * Refresh
    - d/p/u/parser-add-support-for-prompting.patch
      - Add condition in policydb serialization to only encode xtable if
      kernel_supports_permstable32
  * Add patch to add balena-etcher profile (LP: #2046844)
    - d/p/u/profiles-add-unconfined-balena-etcher-profile.patch
  * Fix d/p/u/userns-runtime-disable.patch to work when
    kernel.apparmor_restrict_unprivileged_userns does not exist by adding
    -e to sysctl.
  * d/apparmor.install
    - install new profiles
      - wike - changed installation from apparmor to apparmor.d
      - foliate
      - balena-etcher
      - transmission

  [Alex Murray]
  * Add upstream patch to relax mount rules to fix use of virtiofs and
    other file-system types
    - d/p/u/mountrule-relaxing-constraints-on-fstype.patch
  * Remove patches which got dropped from quilt series earlier
    - d/p/u/parser-support-uin128_t-key-as-a-pair-of-uint64_t-nu.patch
    - d/p/u/Minor-improvements-for-MountRule.patch
  * d/control: Remove obsolete lsb-base Depends and swap pkg-config to
    pkgconf for Build-Depends

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

  * New upstream release.
    (LP: #2046844, LP: #2060100, LP: #2056297)
  * Refresh
    - d/p/u/samba-systemd-interaction.patch
  * Drop patches which have now been applied updatea
    - d/p/u/parser-fix-issues-appointed-by-coverity.patch
    - d/p/u/profiles-add-unconfined-profile-for-tuxedo-control-c.patch
  * Add patch to enable bwrap profile
    - d/p/u/enable-bwrap-profile.patch
      (LP: #2046844, LP: #2065708)
  * d/apparmor.install
    - install new profile
      - bwrap-userns-restrict
  * d/apparmor-profiles.install
    - install new profile
      - unshare-userns-restrict

 -- Georgia Garcia <email address hidden> Tue, 30 Apr 2024 14:12:01 -0300

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for apparmor has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Robie Basak (racb)]

This change was reverted, so I'm reopening the bug task for Noble. See main tracking bug 2064672 and regression bug 2072811 for details.

[Chris Halse Rogers (raof)]

Hello Xavier, or anyone else affected,

Accepted apparmor into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/4.0.1really4.0.1-0ubuntu0.24.04.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted apparmor (4.0.1really4.0.1-0ubuntu0.24.04.3) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

libextractor/unknown (armhf)
libreoffice/4:24.2.5-0ubuntu0.24.04.1 (arm64)
stress-ng/unknown (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#apparmor

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Janne Pulkkinen (matoking)]

`protontricks` requires an AppArmor profile and is currently broken on Ubuntu due to this, unless `--no-bwrap` flag is used. Same as Steam, it uses Steam Runtime which in turn rely on bwrap.

I copied the one from `/etc/apparmor.d/steam` and just adjusted the name and path to point to `/usr/bin/protontricks`. Works fine.

[Georgia Garcia (georgiag)]

Verification completed in bug 2064672

[Tobiyo Kuujikai (fuseteam)]

this did not solve my issue with testing Nextcloud-Talk: https://github.com/nextcloud/talk-desktop/issues/588

i attempted to create an apparmor profile for it but it did not work:
# 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 Nextcloud-Talk /** xattrs=(security.apparmor=Nextcloud-Talk) flags=(unconfined) {
  userns,

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

[Philippe (philippe734)]

For testing, here are two apps AppImage need to run with sandbox and fail to start with Ubuntu 24.04:
https://www.ledger.com/ledger-live
https://www.railway.xyz/#download
Returns:
.....FATAL:setuid_sandbox_host.cc(158)]
The SUID sandbox helper binary was found, but is not configured correctly.
Rather than run without sandboxing I'm aborting now. You need to make sure that /.... is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

I'll test your patchs with these apps in virtual machine with 24.04 and provide to results here.

[John Johansen (jjohansen)]

An updated aa-notify that can prompt the user to create a profile is available in oracular, and for noble via https://launchpad.net/~apparmor-dev/+archive/ubuntu/apparmor-backports. The plan is to get more testing on it and then SRU to noble.

it can be install via
  sudo apt install apparmor-notify

basic instructions are available via
  man aa-notify

it will install a default configuration in "/etc/apparmor/notify.conf". The default configuration can be modified on a per user basis by copying it to "$XDG_CONFIG_HOME/apparmor/notify.conf" which is generally "$HOME/.config/apparmor/notify.conf" or to "$HOME/.apparmor/notify.conf". A custom configuration is not needed unless you want to use filtering to make it less noisy.

Currently regular notifications will happen for all apparmor events, but they can be filtered using the config file.

the notifier can be started via the shell with
  aa-notify -p -s1 --prompt-filter=userns

or by adding it to startup applications

There is a bug with the user namespace notification where it currently requires "--prompt-filter=userns" as part of the command arguments instead of being set in the config file.

[Erich Eickmeyer (eeickmeyer)]

This issue has returned for digikam 8.4.0 on oracular

$ digikam
kf.config.core: Migrating old staterc "" -> "/home/erich/.local/state/digikamstaterc"
QFile::rename: Empty or null file name
kf.config.core: Failed to migrate "" -> "/home/erich/.local/state/digikamstaterc"
digikam.facedb: Cannot found faces engine model "shapepredictor.dat"
digikam.facedb: Faces recognition feature cannot be used!
digikam.facedb: Cannot found faces engine DNN model "openface_nn4.small2.v1.t7"
digikam.facedb: Faces recognition feature cannot be used!
LaunchProcess: failed to execvp:
/usr/lib/qt6/libexec/QtWebEngineProcess
LaunchProcess: failed to execvp:
/usr/lib/qt6/libexec/QtWebEngineProcess
Trace/breakpoint trap (core dumped)

[Andreas Hasenack (ahasenack)]

The current apparmor profile for digikam in oracular has these rules:

  /usr/lib/x86_64-linux-gnu/qt5/libexec/QtWebEngineProcess cx -> &digikam//QtWebEngineProcess,
  /usr/lib/aarch64-linux-gnu/qt5/libexec/QtWebEngineProcess cx -> &digikam//QtWebEngineProcess,
  /usr/lib/arm-linux-gnueabihf/qt5/libexec/QtWebEngineProcess cx -> &digikam//QtWebEngineProcess,

There is not even a qt6 path, which in oracular is indeed without the architecture path component:

$ apt-file find QtWebEngineProcess
apparmor: /etc/apparmor.d/QtWebEngineProcess
libqt5webenginecore5: /usr/lib/aarch64-linux-gnu/qt5/libexec/QtWebEngineProcess
libqt6webenginecore6-bin: /usr/lib/qt6/libexec/QtWebEngineProcess
nsight-compute: /usr/lib/nsight-compute/host/linux-desktop-t210-a64/libexec/QtWebEngineProcess
nsight-systems: /usr/lib/nsight-systems/host-linux-armv8/libexec/QtWebEngineProcess

[Launchpad Janitor (janitor)]

This bug was fixed in the package digikam - 4:8.4.0-3ubuntu2

---------------
digikam (4:8.4.0-3ubuntu2) oracular; urgency=medium

  * Update path for webengineprocess for qt6 in apparmor profile. (LP: #2046844)

 -- Scarlett Moore <email address hidden> Tue, 17 Sep 2024 12:34:55 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor - 4.0.1really4.0.1-0ubuntu0.24.04.3

---------------
apparmor (4.0.1really4.0.1-0ubuntu0.24.04.3) noble; urgency=medium

  * Revert to version 4.0.1-0ubuntu0.24.04.2 except for the patch
    that enables the bwrap-userns-restrict profile (LP: #2072811).
  * New upstream release.
    (LP: #2064672, LP: #2046844, LP: #2060100, LP: #2056297)
  * Drop patches which have now been applied upstream
    - d/p/u/parser-fix-issues-appointed-by-coverity.patch
    - d/p/u/profiles-add-unconfined-profile-for-tuxedo-control-c.patch
    - d/p/u/parser-support-uin128_t-key-as-a-pair-of-uint64_t-nu.patch
    - d/p/u/Minor-improvements-for-MountRule.patch
  * Add patch to add balena-etcher profile (LP: #2046844)
    - d/p/u/profiles-add-unconfined-balena-etcher-profile.patch
  * Add upstream patch to relax mount rules to fix use of virtiofs and
    other file-system types
    - d/p/u/mountrule-relaxing-constraints-on-fstype.patch
  * Refresh
    - d/p/u/samba-systemd-interaction.patch
    - d/p/u/parser-add-support-for-prompting.patch
      - Add condition in policydb serialization to only encode xtable if
      kernel_supports_permstable32
  * Fix d/p/u/userns-runtime-disable.patch to work when
    kernel.apparmor_restrict_unprivileged_userns does not exist by adding
    -e to sysctl.
  * d/apparmor-profiles.install
    - install new profile
      - unshare-userns-restrict
      - bwrap-userns-restrict
  * d/apparmor.install
    - install new profiles
      - wike - changed installation from apparmor to apparmor.d
      - foliate
      - balena-etcher
      - transmission
  * d/control: Remove obsolete lsb-base Depends and swap pkg-config to
    pkgconf for Build-Depends

 -- Georgia Garcia <email address hidden> Thu, 18 Jul 2024 15:28:46 -0300

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/2046844

[Erich Eickmeyer (eeickmeyer)]

All of these apparmor profiles appear to be broken on live sessions for seeded applications, e.g. kalgebra and marble on Edubuntu and digikam on Ubuntu Studio.

[Jaromir Obr (jaromir-obr)]

I'm on Ubuntu 24.04 and I have apparmor 4.0.1really4.0.1-0ubuntu0.24.04.3 where the bug should be fixed.

But I'm getting this:

~/lmstudio$ ./LM_Studio-0.3.3.AppImage
[925145:1005/093654.069946:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_LM_StuOdQy3r/chrome-sandbox is owned by root and has mode 4755.

As a workaround I'm able to run the appimage with "--no-sandbox". Also a running of the app from Nautilus (by a double click) works well.

Any idea?

[Vidar Braut Haarr (vhaarr+launchpad)]

Is this bug supposed to be fixed in oracular with 4.1.0~beta1-0ubuntu3? I need to run with --no-sandbox on existing appimages at least, and it's nearly impossible to do development work on for example electron apps without explicitly setting sysctl -w kernel.apparmor_restrict_unprivileged_userns=0.

[Ondra Medek (xmedeko)]

I have 4.0.1really4.0.1-0ubuntu0.24.04.3 and still have the "LaunchProcess: failed to execvp" problem. We a custom Electron app packaged into a *.deb file. The problem occurs, when the installation dir has a space in the path, e.g. "/opt/Custom App". When we make installation into "/opt/CustomApp" then it starts fine.

Also in the error message, the path with space "/opt/Custom App" is truncated to the first space only:

$ custom-app
LaunchProcess: failed to execvp:
/opt/Custom

(Workaround "sysctl -w kernel.apparmor_restrict_unprivileged_userns=0" works OK).

I think such mishandling spaces in path should be fixed ASAP. See also Electron issue (and many apps it affects) https://github.com/electron/electron/issues/41066

For the problems with SUID, see also electron-builder issue https://github.com/electron-userland/electron-builder/issues/8440 (However, the root of the problem is in Ubuntu 24 apparmor).

[John Johansen (jjohansen)]

@xmedeko The handling of spaces has nothing to do with the user namespace restriction that this bug, and the upstream git hub issue are tracking.

can you attach any additional information. kernel logs etc.

[Georgia Garcia (georgiag)]

Hi Ondra. Could you share what the apparmor profile looks like? Spaces
should work when surrounded by double quotes in the profile. In
4.0.1really4.0.1-0ubuntu0.24.04.3 there's an example of that in
/etc/apparmor.d/MongoDB_Compass.

profile "MongoDB Compass" "/usr/lib/mongodb-compass/MongoDB Compass"
flags=(unconfined) {
  ...
}

Do you see any apparmor messages in your system logs? They could be in
/var/log/syslog or /var/log/kern.log, or if you have auditd installed
/var/log/audit/audit.log

Also note that the "LaunchProcess" message that is truncated is not
emitted by apparmor.

[Ondra Medek (xmedeko)]

@jjohansen @georgiag Thanks for the replies and hints. I didn't have apparmor profile and that fixes the problem. (I have created feature request for electron-builder https://github.com/electron-userland/electron-builder/issues/8635)

Without apparmor profile, an Electron.js app complains: The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/Custom App/chrome-sandbox is owned by root and has mode 4755.

So I set SUID as suggested: sudo chmod 4755 "/opt/Custom App/chrome-sandbox"

And now, if the path is without space (e.g. /opt/CustomApp), then the Electron app works. When it has a space, it fails with "LaunchProcess: failed to execvp" I have mentioned above. (It's possible error message is from Electron.js code.) syslog contains logs (stripped prefixes):

kernel: audit: type=1400 audit(1729968745.234:136): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=2196 comm="custom-app" requested="userns_create" target="unprivileged_userns"
kernel: audit: type=1400 audit(1729968745.236:137): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=2198 comm="custom-app" capability=21 capname="sys_admin"
kernel: traps: custom-app[2196] trap int3 ip:57e938a5c46c sp:7fff1815e5a0 error:0 in custom-app[57e934ad0000+8972000]

So, when I do: mv "/opt/Custom App" "/opt/CustomApp"
It starts working. (And I do not have any apparmor profile for "/opt/CustomApp". The app works with any dir without spaces, e.g /opt/foo too). In syslog, I have just the first message: apparmor="AUDIT"

I've also reported this issue to Electron team https://github.com/electron/electron/issues/44414

[Sam (samluanch)]

I was wondering about the threats being mitigated by disabling unprivileged userns like this. After some searching, I was able to find this rationale: https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626

Now my question becomes: On a system where software like podman or flatpak are installed, wouldn't an unprivileged attacker be able to trivially leverage that software to work around your apparmor limitation? Would there be any security benefit in keeping `kernel.apparmor_restrict_unprivileged_userns` set to 0 with the presence of such software on the system?

For context, I'm trying to evaluate my options since we make extensive use of bwrap in our systems. Currently, all my attempts to fix bwrap ended with `bwrap: setting up uid map: Permission denied` which was finally explained when I discovered this bug.