Many apps are crashing in Mint 22 due to recent changes in apparmor in Ubuntu 24.04: reverse this Ubuntu regression just like snaps

[archisman-panigrahi]

Ubuntu made some changes in apparmor in 24.04, preventing many apps from working. Such apps include Balena Etcher (balena-io/etcher#4184 (comment)), Wike (available on official repositories and also flatpak), Foliate ebook reader, and many more (including all electron based apps electron/electron#41066).

Despite Launchpad saying Fix Released for some of these apps, I verified that wike still crashes in Mint 22 beta.

Here is the output when I run Wike using APT.

mint@mint:~$ wike 
bwrap: Creating new namespace failed: Permission denied 
** (wike:3274): ERROR **: 04:08:47.388: Failed to launch dbus-proxy: Child process exited with code 1 
Trace/breakpoint trap (core dumped)

(This is not a Wike bug. It is because apparmor is preventing wike from running).

While the change was made to improve security, the implementation is buggy. Many apps just crash without any clear GUI error message, and non-expert users may have no idea why they are crashing.

I suggest Mint reverses this immature Ubuntu-specific bug that crashes so many apps (at least until apparmor becomes mature enough), just like the Mint's policy for snap.

Snap is an upstream issue, which Mint took care of, and I suggest the same for apparmor, for better out of the box user experience.

How to fix

The procedure to undo these changes is described here and here

Creating a configuration file /etc/sysctl.d/20-apparmor-mint.conf with the content kernel.apparmor_restrict_unprivileged_userns = 0 fixes the issue permanently (then restart).

It can be done with the following command

echo 'kernel.apparmor_restrict_unprivileged_userns = 0' | 
  sudo tee /etc/sysctl.d/20-apparmor-mint.conf

I suggest this configuration file is added to the default installation of Mint 22, so that the apps will never crash

[archisman-panigrahi]

#71 was a duplicate of this issue. Not just Jitsi, too many useful apps are affected.

[EnlightenedBacon]

Just FYI as a temp workaround, I had this problem with Mullvad VPN and using --no-sandbox makes it work. Not ideal, but usable for now. Interestingly, Mullvad claims their latest release was meant to fix compatibility with 24.04, so perhaps there's a bit more to the issue that's Mint beta specific (or Mullvad just failed at the fix).

[archisman-panigrahi]

Another affected app is freetube FreeTubeApp/FreeTube#5199

[archisman-panigrahi]

Another affected app: Upscayl upscayl/upscayl#902

[Qronikarz]

Another affected program is the Steam Flatpak (notice: it was because of apparmor 4.0.1-0ubuntu0.24.04.2 update because I had no problems with Steam games on Mint 22 before). There are few workarounds:
flathub/com.valvesoftware.Steam#1318

Anyway, Does Mint even use apparmor for anything? Can't it be just thrown away like snaps?
Solus decided recently that they no longer need that - https://discuss.getsol.us/d/10750-dropping-apparmor-kernel-patches

[haggen88]

bug report marked ‘fix committed’: https://launchpad.net/ubuntu/+source/apparmor/4.0.1really4.0.0-beta3-0ubuntu0.1

[archisman-panigrahi]

@haggen88 The way they implemented it, they have to manually add a fix almost every single electron/web app out there, which is never going to happen.
After reading the Solus article, it seems that in order to enable confinement of snaps, they ended up breaking apt/flatpak packages.

[clefebvre]

Here's my take on this:

• User namespaces are a feature of the kernel. It's a feature which is supported by the Linux kernel. When a vulnerability is found, it's given a CVE and the code is fixed appropriately. If the kernel developers wanted to disable this feature by default, or restrict it, they could do so themselves.
• The mentioned CVEs are indeed patched. Their exploit didn't just require user namespaces, it requires local user access (which we consider, by the nature of our audience, as a sufficient way to gain privilege already).
• The measures taken by Ubuntu to disable this feature and having an opt-in via apparmor profile isn't ideal because.. 1) it's Ubuntu-specific. 2) It's elective, by providing specific profiles for specific apps we'll always see new apps fail (especially since they work in other distros).. It might take years for Ubuntu to tune its collection of profiles, assuming they manage to do so. 3) It's limited. It shows its limitation when it comes to sandboxing technologies, electron apps, appimage etc..

Whether user namespaces continue to be enabled by default or not in the future, I think we need a global solution to this. Not something specific to Ubuntu, and not something elective and rushed like this.

We'll need to keep an eye on this and reconsider eventually, but for now, we'll reenable this feature in Linux Mint 22.

[clefebvre]

/etc/sysctl.d/20-apparmor-mint.conf is now provided by ubuntu-system-adjustments 2024.07.17.

[archisman-panigrahi]

Whether user namespaces continue to be enabled by default or not in the future, I think we need a global solution to this.

Can someone (with more knowledge about this than me) tell us what is the stance of every major distro regarding this?

[mcatanzaro]

There is an Ubuntu bug report here.

Can someone (with more knowledge about this than me) tell us what is the stance of every major distro regarding this?

I think Ubuntu is the only major distro restricting user namespace creation nowadays, though this might depend on your definition of "major." Debian notably did not allow unprivileged user namespaces until Debian 11 (Bullseye).

My $0.02 is that reverting the AppArmor policy changes was the right call, at least until Ubuntu figures out how to unbreak affected applications. User namespaces are the foundation of Linux desktop sandboxing; if you cannot create sandboxes, that's surely the worst possible security outcome by far. That's why WebKit apps are crashing. (Workaround: set the environment variable WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 if you dare.)

There is an alternative to user namespaces: you probably don't need user namespaces if you build bubblewrap as a setuid root executable instead. (I say probably because it's been a few years since it was common for distros to do this, so maybe something unexpected would break.) This was how bubblewrap was originally deployed years ago before unprivileged user namespaces were commonly available, and it's still supported as a legacy option, but the cost is maybe setuid root is a bigger security risk than user namespaces. I would say probably.

The Ubuntu blog post recommends that affected applications ship their own AppArmor profiles, but that seems unlikely.

[archisman-panigrahi]

The Ubuntu blog post recommends that affected applications ship their own AppArmor profiles, but that seems unlikely.

If a nasty developer wants to create a malware, they can also ship their own apparmor profile (which will be installed during the .deb package installation), right? So, as long as the user provides the password during the installation of the software, there is really no way such attacks can be prevented.

[mcatanzaro]

(The goal of the restrictions on unprivileged user namespaces is to protect against malicious input that compromises non-malicious applications. Of course installing software that is itself malicious is not going to end well.)