Electron-based AppImages fail on Deepin Linux

[probonopd]

Solution: Deepin Linux should be configured to allow unprivileged namespaces: https://docs.appimage.org/user-guide/troubleshooting.html#i-have-issues-with-electron-based-appimages-and-their-sandboxing

Please create a file /etc/sysctl.d/00-local-userns.conf with the following content:

echo kernel.unprivileged_userns_clone = 1

Then, Electron-based AppImages should work.

cc @shouhuanxiaoji

[andersruneson]

I'm not sure this is related, but it looks like the same error, see below.

I get this when trying to run newer versions of Cursor.com, issue at cursor forum.

How do I run these appimages with go-appimage? @probonopd I already have kernel.unprivileged_userns_clone=1, so I don't think that's the issue.

Currently I need to start cursor by running from the commandline to get the argument --no-sandbox.

The setuid sandbox is not running as root. Common causes:
  * An unprivileged process using ptrace on it, like a debugger.
  * A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...)
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted
[3616548:0311/112540.445877:FATAL:zygote_host_impl_linux.cc(201)] Check failed: . : Invalid argument (22)
Trace/breakpoint trap (core dumped)

[asvishnyakov]

Just run into the same issue, but in my case AppImage itself works fine (when ~~called from console~~ or by double-click), but I can't launch application from a list of applications or icon pinned at Dash in Ubuntu

UPD. Only double click or Run command work, running from console cause the same issue.

[probonopd]

@asvishnyakov which exact Ubuntu version are you using? Can you reproduce this with one of the Ubuntu Live ISOs? Which one? Using which exact AppImage? Thank you very much.

[Samueru-sama]

The issue is this restriction of namespaces that ubuntu added on 24.04: https://github.com/linuxmint/mint22-beta/issues/82

TLDR: The fix is echo 'kernel.apparmor_restrict_unprivileged_userns = 0' | sudo tee /etc/sysctl.d/20-canonical-moment.conf

[asvishnyakov]

@probonopd I'm trying to run Cursor 0.49.6. Here is results on Ubuntu 24.04.2:

Installed:

• [x] Run from UI - works
• [ ] Run from console - fails with error

The setuid sandbox is not running as root. Common causes:

• An unprivileged process using ptrace on it, like a debugger.
• A parent process set prctl(PR_SET_NO_NEW_PRIVS, ...) Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted [8709:0505/025135.919355:FATAL:zygote_host_impl_linux.cc(207)] Check failed: . : Invalid argument (22) Trace/breakpoint trap (core dumped)

Live CD (same version):

• [ ] Run from UI - don't work without any error/exception shown
• [ ] Run from console - fails with error

./Cursor.AppImage [11857:0505/004134.896167:FATAL:credentials.cc(131)] Check failed: . : Permission denied (13) Trace/breakpoint trap (core dumped)

P.S. kernel.apparmor_restrict_unprivileged_userns = 0 is NOT appropritate fix, but instead only temporary workaround, as it completely disables AppArmor and by so reduces overall system security.

[Samueru-sama]

P.S. kernel.apparmor_restrict_unprivileged_userns = 0 is NOT appropritate fix, but instead only temporary workaround, as it completely disables AppArmor and by so reduces overall system security.

There is no security issue with enabling unpriv namespaces, these kernel patches are something that kernel devs have rejected over and over again. Hasn't stopped ubuntu from breaking it anyway.

See https://github.com/linuxmint/mint22-beta/issues/82 and https://getsol.us/2024/07/15/dropping-apparmor-kernel-patches/

What's not safe is what a lot of electron apps and also snaps are doing now, which is running with --no-sandbox to avoid using namespaces.

[asvishnyakov]

@Samueru-sama

Excuse me, but with all due respect, these are not Linux kernel developers - it's teams behind two different Linux distributions, one of which is relatively unknown and the other a derivative of Ubuntu.

Anyway, AppArmor is enabled by default in both Debian and Ubuntu. It's fine to say that apparmor_restrict_unprivileged_userns is required as a temporary workaround, but if the issue can be resolved by creating an AppArmor profile for the AppImage services and/or the images themselves, that would be a much better long-term solution.

What matters most to me is that it works when the user simply clicks “Run” in the UI. I believe understanding why that works is key to resolving this efficiently - without requiring users to undo something their system vendor has enabled by default.

[Samueru-sama]

Excuse me, but with all due respect, these are not Linux kernel developers

Alright why haven't the apparmor patches been upstreamed as well as all other patches that allow disabling userns to the kernel then? 👀

Even the sysctl option to disable userns is not upstreamed into the kernel because kernel devs don't agree with it, instead some distros just add the patch.

but if the issue can be resolved by creating an AppArmor profile for the AppImage services and/or the images themselves, that would be a much better long-term solution.

• Making said profile requires elevated privileges, already bad idea.

• If you allow an application that you have write access to, it makes no sense, any malware can replace it and use the permission granted by apparmor in its place. It makes no sense to bother with it.

without requiring users to undo something their system vendor has enabled by default.

Or maybe just switch to the many forks of ubuntu that already have this disabled. Or use snap and hopefully the packager didn't just hack --no-sandbox into it and actually bothered with playing with ubuntu's nonsense 😆

[asvishnyakov]

@Samueru-sama Thank you for your honest opinion, but I don't find this conversation productive.

@probonopd Here is working AppArmor profile for app images:

# 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 appimages /**/*.AppImage flags=(unconfined) {
  userns,

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

How to create an run:

sudo nano /etc/apparmor.d/appimages
sudo apparmor_parser -r /etc/apparmor.d/appimages

A few notes:

1. I'm not an expert in this area, so please do your own research before including this in your app or documentation.
2. Based on the documentation I found, this profile appears to:
   1. Create an AppArmor profile named appimages.
   2. Apply it on the fly to all *.AppImage files found on the system (you don’t need to re-run it each time you download a new AppImage).
   3. Mark them as unconfined, meaning no additional restrictions are applied.
   4. Enable the use of unprivileged namespaces.
   5. Allow user-specific rules from local profiles with the same name to be applied.
3. This profile is based on the profiles used by Chrome and Docker Desktop.
4. This profile can only be used on Ubuntu 23.10 or later, as it requires AppArmor ABI v4.0.

It allowed me to run Cursor from the console, the application list, and the icon pinned to the Dash in Ubuntu

[Samueru-sama]

Making a profile that allow any file that ends with .AppImage is just the same as adding kernel.apparmor_restrict_unprivileged_userns = with extra steps.

And it is flawed, because this expects that the user will keep the .AppImage extension.

Also I just booted a vm to check something, the profiles can be read by anyone lol

So any malware just has to either check if there is a profile that allows a file in a location that doesn't need privileges to get written to, like this profile, or get more sophisticated using LD_PRELOAD to hijack existing allowed applications.

Not to mention none of this stops anything from just making a sudo wrapper first in PATH to capture the users password when they update, amazing job by ubuntu's security department 👀