feat(appimage): If necessary, start with --no-sandbox

[sabonerune]

fix #8440

The method in #4496 has the following drawbacks:

• Doesn't work without desktop integration
  The AppImage can be launched without desktop integration.
  It also doesn't work when started from the command line.
• Sandbox is always disabled
  user namespace should now be available on many Linux systems.
  This means that --no-sandbox is only needed in limited environments.
  Even in Ubuntu 24.04 or later, starting from file manager bypasses AppArmor restrictions, so --no-sandbox is not required.
  https://discourse.ubuntu.com/t/understanding-apparmor-user-namespace-restriction/58007#p-148026-bypassing-apparmor-security-restriction
  It's also possible that the user has disabled AppArmor.

This solves these problems by automatically detecting when the user namespace is unavailable and adding --no-sandbox at runtime.

[changeset-bot]

🦋 Changeset detected

Latest commit: 67c5e5f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages

Name	Type
app-builder-lib	Major
dmg-builder	Major
electron-builder-squirrel-windows	Major
electron-builder	Major
electron-forge-maker-appimage	Major
electron-forge-maker-nsis-web	Major
electron-forge-maker-nsis	Major
electron-forge-maker-snap	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[absidue]

I would suggest changing the pull request title and changelog entry, as it sounds like you are adding the --no-sandbox flag in more cases, but the goal of this pull request is to add that flag in less cases. Something along the lines of: "feat: Only start AppImage with --no-sandbox when necessary" would be more clear.

[Copilot]

Pull request overview

This PR improves how AppImages handle the need for --no-sandbox on Linux systems where user namespaces are unavailable. Instead of always hardcoding --no-sandbox in the desktop entry (the previous approach from PR #4496), the new approach dynamically detects at runtime whether user namespaces work, and only adds --no-sandbox when they don't. This addresses users on modern Linux systems (e.g., Ubuntu 24.04) where user namespaces may be available, while still working on restricted environments.

Changes:

• The generated AppRun shell script (for appimage toolset 1.0.2) now includes runtime logic to detect if user namespaces are unavailable (unshare -Ur true) and conditionally adds --no-sandbox when launching the app binary.
• The desktop entry Exec field no longer hardcodes --no-sandbox for the 1.0.2 toolset (it still does for the legacy 0.0.0 toolset to maintain backwards compatibility).
• A changeset entry documents the change as a minor feature.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
packages/app-builder-lib/src/targets/appimage/AppImageTarget.ts	Removes --no-sandbox from the desktop entry Exec field for the 1.0.2 toolset; legacy 0.0.0 toolset retains it
packages/app-builder-lib/src/targets/appimage/appImageUtil.ts	Adds shell logic to the generated AppRun script to dynamically detect user namespace availability and conditionally set --no-sandbox
test/snapshots/linux/linuxPackagerTest.js.snap	Updates snapshot for 1.0.2 desktop entry to reflect the removed --no-sandbox
.changeset/dull-carpets-stick.md	Changeset for the new minor feature

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mmaietta]

Looks like we have some tsc errors. Can you please TAL when you have a chance

[Nantris]

starting from file manager bypasses AppArmor restrictions, so --no-sandbox is not required.

I have not found this to be the case in Kubuntu. I don't know if this is Ubuntu specific but I've used every recent version of Kubuntu and this doesn't match my experience in any of them.

---

Would you happen to have a moment to elaborate this point?

user namespace should now be available on many Linux systems.
This means that --no-sandbox is only needed in limited environments.

[Nantris]

Just to add, on Kubuntu in Dolphin if you try to launch an AppImage it fails with:

"For security reasons, launching executables is not allowed in this context."

My understanding is Ubuntu will close this route soon in Nautilus.

More importantly, I'm skeptical that using --no-sandbox is as trivial and free from risk as the initial comment suggests. --no-sandbox doesn't just skip namespace creation - it disables all renderer sandboxing. This means any renderer exploit becomes direct code execution as the user, whereas with the sandbox, a renderer exploit is contained to the sandbox barring a second exploit to escape it.

[sabonerune]

@Nantris

Would you happen to have a moment to elaborate this point?

To be honest, I'm not very familiar with Linux distributions.
However, I thought that most Linux distributions, excluding those based on Ubuntu 24.04 or later, could be booted without --no-sandbox, unlike in #4469.

---

Prior to this pull request, it wouldn't work if desktop integration wasn't enabled, and if it was enabled, --no-sandbox was added even if it wasn't necessary.

I simply made this behavior more as intended.

If you believe the application should not automatically add --no-sandbox when it starts, it would be better to create a new issue.

[Nantris]

Thanks for your reply @sabonerune.

Before I make another issue, can you clarify if this behavior is on by default where kernel.apparmor_restrict_unprivileged_userns === 1? It seems to be, and if so I will create another issue regarding concerns. Thank you.

[sabonerune]

@Nantris
If kernel.apparmor_restrict_unprivileged_userns === 1, then in most cases, executing unshare -Ur true will fail.
Therefore, --no-sandbox is added.
However, if AppArmor is bypassed or permitted by the profile, it will launch without --no-sandbox as it will successfully execute unshare -Ur true.

[mmaietta]

Hi folks, attempting to catch up here. What was the resolution and decision? (and/or created issues? CC @Nantris)

Need to understand if this PR is an acceptable change before any release is pushed out.

[Nantris]

@mmaietta I've not gotten around to making a new issue but did plan to.

I'm skeptical of this being activated by default. I see far less issue with it being opt-in.

I suspect most developers using electron-builder will not be aware their app is running with --no-sandbox, much less their end-users. It's debatable whether users need to know that detail, but certainly the developer responsible for the security model needs to know, at least in my view.

[absidue]

@Nantris Before this pull request --no-sandbox was always passed to Electron, with this pull request it is only passed when needed, which is an improvement.

[Nantris]

@absidue thank you for the correction - I overlooked that. With that in mind the PR seems unquestionably an improvement over the current code.

However if I'm reading the git blame properly the inclusion of --no-sandbox at all is a development from around a month ago which still makes it a recent change worth real consideration, and I don't think electron-builder should ever configure the app with --no-sandbox unless the developer who is using electron-builder specifically opts in.

Am I interpreting the code properly that this is only for desktop shortcuts? I don't think it's good security practice to be bypassing it even selectively without being explicitly opt-in.

[Nantris]

Lazily created #9659 so further discussion of the use of --no-sandbox itself can happen there.

[sabonerune]

@Nantris AppRun is the entry point for AppImage.
Therefore, this code is always executed.
https://docs.appimage.org/reference/appdir.html#general-description