Electron: The SUID sandbox helper binary was found, but is not configured correctly

Unfortunately there's no way we can configure this correctly automatically, because setting the appropriate permissions requires root privileges and we don't want to ask for a root password during npm install.

Ideally, Arch would configure its kernel support unprivileged CLONE_NEWUSER and Chromium (and Electron) could use the namespace sandbox instead of relying on the old setuid sandbox. Apps that are distributed on Linux will need to incorporate this into their install process. See https://github.com/electron-userland/electron-installer-debian/pull/184 and https://github.com/electron-userland/electron-installer-redhat/pull/112 for example.

During development, we should probably print something out on npm install though with instructions if we detect that the namespace sandbox isn't available.

Hey, thanks for the super quick response!

Does unprivileged CLONE_NEWUSER come from CONFIG_USER_NS=y? If so, that should be the current configuration.

Please let me know if there's anything I can do to help, or if this is expected output on Arch I'm happy to close -- I understand that there's some jankiness to be expected when running bleeding-edge distros and I don't mind resolving this in a PKGBUILD rather than expecting it to work perfectly straight out of npm. Cheers!

CONFIG_USER_NS=y enables the user namespaces feature, but they're still restricted to privileged users by default. This suggests sysctl kernel.unprivileged_userns_clone=1

Is there a possible workaround in the meantime until every linux distro enables those features?

@kitingChris The setuid sandbox IS the workaround. You just need to ensure that when developing / releasing an electron app your dev / packaging scripts set the permissions of the sandbox helper correctly as @nornagon linked above.

Is there a possible workaround in the meantime until every linux distro enables those features?

See the original message:

If I chown and chmod the file then it works fine

Also see here https://github.com/electron/electron/issues/16631#issuecomment-476082063 So to make suid sandbox work you basically have to tweak the chrome-sandbox binary this way:

• sudo chown root chrome-sandbox
• chmod 4755 chrome-sandbox

The issue is more severe though if running appimage/snap packages, I have not yet revealed a decent workaround for these cases. It's working if appimage is executed with --no-sandbox arguemnt, but this is a hack.

@nornagon

because setting the appropriate permissions requires root privileges and we don't want to ask for a root password during npm install.

Executing chmod 4755 node_modules/electron/dist/chrome-sandbox doesn't require root permission and that should be enough to run such command for wrapping the app to deb/pacman/etc packages as when such packages get installed all the files including chrome-sandbox normally owned by root. So it would be great electron does chmod 4755 node_modules/electron/dist/chrome-sandbox automatically during installation process as then there would be no need to handle this case manually like mentioned here.

CONFIG_USER_NS=y enables the user namespaces feature, but they're still restricted to privileged users by default. This suggests sysctl kernel.unprivileged_userns_clone=1

I confirm executing sudo sysctl kernel.unprivileged_userns_clone=1 is another workaround, related comment.

@vladimiry I needed to first chown and then chmod. The other way round it didn't work.

@burningTyger you are right, I just have changed the original message.

@nornagon If we chmod 4755 out/Release/chrome-sandbox on CI will that permission be persisted once we zip it up or do we have to make this change in electron-download to fix the permission on DL?

same here is bad new fonction for what need to change that... :(

@MarshallOfSound zip does not support permissions, but ultimately the issue is not the chmod permission, but rather the owner. The setuid sandbox helper is suid _to root_, because it needs to perform functions that are only available to root. If it were possible to set the appropriate permissions without first gaining root privileges, that would be a very serious vulnerability in Linux. Fortunately for Linux, and unfortunately for us, that is not the case.

Here are the options as I see them:

1. Change nothing in Electron. Recommend that developers enable unprivileged CLONE_USERNS on their kernel to allow the namespace sandbox to run instead of the setuid sandbox.
2. Boot without sandbox if no sandboxing method is available _only when booting an unpackaged app_. If Electron is booting a packaged app, refuse to boot without sandbox.
3. In all cases, if no sandboxing method is available, boot without sandboxing and print a warning.
4. Disable sandboxing by default on Linux.

I'm leaning towards (2). It would ease development without compromising the security of the deployed app.

I'm not yet sure what to do about snap/flatpak, as I'm not familiar with their workings. It's possible that they already sandbox the app sufficiently that we can disable sandboxing altogether in that situation, as we do when building the Mac App Store version of Electron.

As for now, I like more the first option.

1. Boot without sandbox if no sandboxing method is available only when booting an unpackaged app. If Electron is booting a packaged app, refuse to boot without sandbox.

Such scenario would be somehow misleading. One might be successfully running unpackaged app without sandboxing, but there is a chance that the packaged app won't work the same way with enabled sandboxing. Like, for example, the case when you access the main process from the renderer process not through the remote interface. Or the case of wrapping the app to AppImage / Snap / Flatpak packages.

1. In all cases, if no sandboxing method is available, boot without sandboxing and print a warning.

So a packaged app that was designed and developed as sandboxed might be executed without sandbox if no sandbox available. This doesn't sound good to me.

1. Disable sandboxing by default on Linux.

What does it mean exactly? What would be the way to enable sandboxing on Linux in the way the app either starts or fails if no sandboxing available (the current situation, forced sandboxing).

I also like (1), but to defend (2) a little, the API exposed to the app wouldn't change when disabling the sandbox. The only thing we would disable is the OS-level sandbox. We would still load the app the same way, it just wouldn't be protected by the OS.

We would still load the app the same way, it just wouldn't be protected by the OS.

Then it sounds good to me too. Thanks for the explanation.

I do not like 2., because optional security generally leads to people disabling the security.

Stepping into the "stupid user" shoes now, I would rather see Electron work by default. If it's a very important security measure, give me a warning and a good explanation of why I need to do extra work. If it's not that important, then don't give me the bad "it doesn't work" taste.

Because of this, I like 1. (with a force quit, like now) or 4.

:x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox raises some red flags for me.

Just to be very clear on what it does: It sets the SUID bit on chrome-sandbox, which makes _any user_ able to execute the file _as root_. This means that if there is any way to use chrome-sandbox maliciously, or if the contents ever gets malicious, any user could become root. chrome-sandbox would be a very interesting target for attack.

I strongly recommend against doing this workaround on npm install, because it would require sudo (user needs to write password), it's invasive and we might not understand the security consequences of doing so.

chown root:root chrome-sandbox && chmod 4755 chrome-sandbox raises some red flags for me.

Of course, it does. But you can enable User Namespace sandboxing as an alternative sudo sysctl kernel.unprivileged_userns_clone=1 (enabled by default on Ubuntu but not on Arch).

Just to be very clear on what it does: It sets the SUID bit on chrome-sandbox, which makes _any user_ able to execute the file _as root_. This means that if there is any way to use chrome-sandbox maliciously, or if the contents ever gets malicious, any user could become root. chrome-sandbox would be a very interesting target for attack.

Yes, but also this binary is the exact same one that comes with Chrome, so if you're worried about this you should probably also uninstall Chrome :)

Is there a way to run without the sandbox / run without the "sandbox helper" ? Got the first users complaining 😅
I expected this to disable the sandbox, but still get the The SUID sandbox helper binary was found, but is not configured correctly error.
I would hate to roll back to electron 4.x 🤨

Error message

Snapcraft Review & suid

I tried uploading a snap with suid flag on chrome-sandbox but the review process from snapcraft forbids the usage of suid flags.

The store was unable to accept this snap.
  - checksums do not match. Please ensure the snap is created with either 'snapcraft pack <DIR>' (using snapcraft >= 2.38) or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs -no-fragments'. If using electron-builder, please upgrade to latest stable (>= 20.14.7). See https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/17 for details.
  - found errors in file output: unusual mode 'rwsr-xr-x' for entry './chrome-sandbox'

@thomasnordquist to disable OS-level sandboxing --no-sandbox needs to be passed as an app argument, ie app.commandLine.appendSwitch won't be enough. Regarding a Snap package, you might want to try adding a plug like described here. Not sure if that will help as I have not tried it yet, would be great if you do. For now I prefer releasing the app I've been building in mixed mode :smile:. Electron v5 is used for all the packages except AppImage and Snap as it's not yet entirely clear how to make these packages work well with sandboxing enabled, but it's going to be clear at some point.

If Snapcraft forbids suid flags then probably the only option is to disable Electron's sandboxing entirely in Snapcraft and rely on the container that Snapcraft uses. I'm not sure what the best way is to do that—is it possible to specify additional command-line flags when packaging through Snapcraft? If so, we could add the --no-sandbox flag. If not, we might need to add some specific detection mechanism to detect running in Snapcraft/Flatpak and disable sandboxing based on that detection.

Some Snap related documentation https://docs.snapcraft.io/browser-support-interface

@posix4e can you shed some light on the issue of running sandboxed Snap package in both User Namespace and SUID sandbox/fallback modes? Looks like you have got a relevant experience of tweaking snap config of the Brave Browser. CC @flexiondotorg.

Just to be very clear on what it does: It sets the SUID bit on chrome-sandbox, which makes _any user_ able to execute the file _as root_. This means that if there is any way to use chrome-sandbox maliciously, or if the contents ever gets malicious, any user could become root. chrome-sandbox would be a very interesting target for attack.

Yes, but also this binary is the exact same one that comes with Chrome, so if you're worried about this you should probably also uninstall Chrome :)

I am partly worried about letting a binary from Chrome have root:root with SUID set, yes. Very little code is without bugs. Here is the source code, for the record: https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

But I am more worried if npm install would:

1. Download a bunch of software on-the-fly.
2. Automatically make one of the files root:root and SUID.

I think that would be the first software stack I know about that automatically does a sudo chown root:root && sudo chmod 4755 on a file owned by a non-root user.

Doing a sudo chown root:root && sudo chmod 475 on npm install should be out of the question, npm would need to run as root to set the permissions. The hook model of npm would allow all installed packages to run their hooks as root as well. With possibly hundreds of packages & nested dependcies, this would be very dangerous.

Doing a sudo chown root:root && sudo chmod 475 on npm install should be out of the question

This is not considered as an option as far as I understand.

I agree that doing anything that would require root privileges during npm install is a non-starter. Which is why I did not list it as one of the options.

For what it's worth, electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0, and electron-installer-snap 3.2.0 have been released with the SUID sandbox changes. Electron Forge v5 and v6 beta should transitively be updated as well (via in-range version updates, use npm update or yarn upgrade appropriately).

Just linking the related code for clarity.

Just to be clear, for Snaps there was more to it (namely, adding browser sandbox support as noted above). See the associated PR's changes for details.

I just hit this, chown / chmod works, but that is not the only necessary action to be taken if you are running inside a Docker image.

If you just do that, you will receive another error:

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

The fix for that is to add --privileged to the docker run command. I don't think this is a good solution, mainly on CI.

@JCMais it sounds like Electron is incorrectly attempting to use the namespace sandbox within docker, even though it should be trying to use the suid sandbox. I'm not sure why that would be, but you can force the suid sandbox with --disable-namespace-sandbox. If you launch docker with --privileged (or --cap-add SYS_ADMIN, or a custom seccomp profile that allows CLONE_NEWUSER), then namespaces will be available inside the sandbox and there's no need for the setuid sandbox or its helper executable.

Like @thomasnordquist I ended up for now disabling sandboxing for Snap/AppImage packages using preload script. You create preload-like sh script named as original binary which then used for loading renamed/original electron binary with --no-sandbox argument. It's convenient to do in electron-builder's after-pack script

@nornagon how exactly I should pass this flag to electron? I tried just adding --disable-namespace-sandbox but it keeps giving me an error:

:~$ electron --disable-namespace-sandbox
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Can confirm that this nuked me in snap and all our Linux users are stuck on an old version until I can remedy this.

I'm TOTALLY for a way to improve security but this was shipped without a feature flag to turn it off.

I'd also like to argue that this shouldn't have been shipped without a feature to disable it via code. I guess maybe this was accidental though because --no-sandbox doesn't work unless manually given from the command line.

If there's something wrong with how electron-installer-snap has implemented sandbox support, please let me know in its issue tracker.

If there's something wrong with how electron-installer-snap has implemented sandbox support, please let me know in its issue tracker.

I'd also like to hear someone confirms that the change is sufficient to tackle the issue with Snap packages. So both positive/negative feedbacks are welcomed. See related info.

@vladimiry I went ahead and tested that and it didn't work.

I need a solution that doesn't resolve around OS patches, sysctl, or reboots. I need something that just workes now. --no-sandbox would be preferred.

It would be much more helpful to me if someone can provide a minimal Electron app that I could use to reproduce the non-functioning packaged Snap. I used a fork of electron-quick-start to build a Snap in CircleCI and installed it on my (Debian Stretch) laptop to verify that my changes at least built a functioning Electron app.

"Didn't work" doesn't help me pinpoint what I can do in electron-installer-snap for it to package correctly for others.

@burtonator, thanks for testing the stuff. As far as I know, packaged into the Snap/AppImage build loader-like bash/sh script that starts the original binary/electron with --no-sandbox cmd argument is the only verified workaround for now.

@malept before testing the stuff there is a need to disable the User Namespace OS feature by executing sudo sysctl kernel.unprivileged_userns_clone=0.

@vladimiry yeah, my laptop already has that userns setting.

If anyone is looking for a solution to this check out @thomasnordquist's solution or my adaptation of it, they work by disabling the sandbox under Linux.

@fabiospampinato your adaptation disables the sandbox for all Linux package types but at least DEB and Pacman packages work well with SUID sandbox (probably all the not container-like packages), there is just a need to set SUID permission bit to chrome-sandbox binary. But don't set SUID permission bit for Snap package as Snap Store rejects such kinds of packages. So I set SUID bit for all the Linux packages expect Snap/AppImage packages which get disabled sandboxing, related code.

CONFIG_USER_NS=y enables the user namespaces feature, but they're still restricted to privileged users by default. This suggests sysctl kernel.unprivileged_userns_clone=1

I confirm executing sudo sysctl kernel.unprivileged_userns_clone=1 is another workaround, related comment.

Thanks mate, working for me! @vladimiry

do you guys know if it works now with 5.0.2?

@p3x-robot No mention of this issue in the changelog. Just checked to be sure and the error is still there for me.

@rybaczewa thanks for the response, i keep on v4 as well, as it is a big issue, cant wait until v5 is working, ciao

cant wait until v5 is working

v5 is working

To be clear to folks in this thread @p3x-robot @rybaczewa this issue is left open for informational / downstream purposes. Electron itself is working as expected and there is nothing here for us to "fix".

If you are seeing this log message you need to either run sudo sysctl kernel.unprivileged_userns_clone=1 or give the chrome_sandbox binary the correct permissions as outlined in the error message.

@vladimiry @MarshallOfSound why are you saying this is fixed? In Snap, I cant install my apps P3X Redis and P3X Onenote neither sudo sysctl kernel.unprivileged_userns_clone=1 or give the chrome_sandbox v5.0.x. I can only install with v4.x.x

You think a user will want to use sudo? They will think this program is bad and they will uninstall the app..
The v5 versions or v6 or v7 is not working right, hence this is a bug:

@p3x-robot snap support as indicated above is down to how you make the snap. electron-installer-snap has support for this out of the box and as mentioned above if that module has issues / is not working please raise an issue on that module.

Please see the electron-installer-snap repo for details or the snapcraft docs on browser sandboxing

To reiterate, my current understanding here is that there is no bug to be fixed, Electron's sandbox is operating as expected. What is being discussed here are issues people are facing with packaging the chrome_sandbox binary

this is weird, becuase i alread added sandbox:

app.enableSandbox()
app.commandLine.appendSwitch('no-sandbox')

output:

patrikx3@bitang:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ /snap/bin/p3x-redis-ui 
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
[12999:0525/085646.618618:FATAL:setuid_sandbox_host.cc(157)] 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 /snap/p3x-redis-ui/5/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)
patrikx3@bitang:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ 

I try this as: app.enableSandbox() , but I get:

Uncaught ReferenceError: require is not defined
    at onload.js:1

If I remove the line, it works.

@MarshallOfSound i am using electron-builder

for all of you, if you want to make it to work, i created a helper:
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
if you are using electron-builder, you add it like this:

for all of you, if you want to make it to work, i created a helper:

Such solution has already been many times mentioned in this issue discussion, this is why I wrote before that electron v5 is working.

@vladimiry thanks, i missed this solution, i just added a javascript native solution instead of typescript...

the only problem is that when i this after pack hack, it is not using on the panel the icon from electron, but it generates a 2nd icon, do you guys how that can be resolved? I think it is the no-sandbox flag does it. anyone?

it only happening with the --no-sandbox:

@fabiospampinato your adaptation disables the sandbox for all Linux package types but at least DEB and Pacman packages work well with SUID sandbox (probably all the not container-like packages), there is just a need to set SUID permission bit to chrome-sandbox binary. But don't set SUID permission bit for Snap package as Snap Store rejects such kinds of packages. So I set SUID bit for all the Linux packages expect Snap/AppImage packages which get disabled sandboxing, related code.

do you guys know how I can keep one icon instead of two?

https://github.com/electron-userland/electron-builder/issues/3872

https://github.com/patrikx3/onenote/issues/65

@p3x-robot there is a way of adding --no-sandbox argument to the packaged to Snap container app without introducing a preloader-like bash/sh script:

• Unpack the snap first by running unsquashfs your-snap-file.snap.
• Edit ./squashfs-root/command.sh by adding needed arguments there.
• Pack the ./squashfs-root folder back to snap package by executing snapcraft pack ./squashfs-root command.

I didn't try but I think the similar repackaging action can be applied to the AppImage package too, ie a matter of executing different unpack/pack commands.

I guess the described repackaging actions can be triggered in afterAllArtifactBuild electron-builder's hook.

@vladimiry thanks, so much, for the one is interesting for the afterAllArtifactBuild, i will try to change the command.sh without unpacking, but it is for tomorrow, thanks again!

the one is interesting for the afterAllArtifactBuild

@p3x-robot afterAllArtifactBuild hook actually is not being triggered as I expected, but it's quite easy to trigger the Snap or any other package type building programmatically. See here the code sample. snapFile is the outcome file here, so you can unpack/unsquashfs it then, apply needed changes and pack back/snapcraft pack. In the example code I pack the Hunspell dictionaries into the Snap's ./usr/share/hunspell folder.

@vladimiry i just use Electron v4, as that is working. I think someone will fix this.

@p3x-robot I still tend to think that you have to admit that there is nothing to fix.

@vladimiry there is nothing to fix, sure. :)

anyone knows if Electron v5.0.2 working with the sandbox issue?

It's, same as v.5.0.0 :smile:

I hope this is not off topic but for AppImages on Debian (9) I get the error:

The setuid sandbox is not running as root. 

Correct me if I'm wrong but I understand (mainly from this discussion) that this is caused by the disabled user namespaces feature which is disabled by default on Debian.

So regarding this suggestion:

1. Change nothing in Electron. Recommend that developers enable unprivileged CLONE_USERNS on their kernel to allow the namespace sandbox to run instead of the setuid sandbox.

I would like to display a message to users saying that it only works when the user namespaces feature is enabled (with maybe a hint on how to do it) and suggest to use the .deb package as an alternative.

How I could implement such a message before the error is shown? Is there a way to prepend a custom script to the AppRun of the AppImage without unpacking and repacking?

Is there a way to prepend a custom script to the AppRun of the AppImage without unpacking and repacking?

@gcascio there were messages in the thread about using loader-like sh script which can be injected by afterpack script.

Thank's for your reply. But I think that the generated AppRun is not available when afterpack is called or am I wrong, at least I can not find it in appOutDir?

I think that the generated AppRun is not available when afterpack is called

I was writing about using loader-like sh script but not about patching AppRun script. If you want to patch the AppRun script there seems to be no way to do so without repackaging.

Ok right I misunderstood. I'll might go with repacking then thank's.

I'll might go with repacking then thank's.

@gcascio in the case you need a template.

i a same "The SUID sandbox helper binary was found" error but on snap file after install
how can fix this

@vladimiry I am working in an online IDE Docker called http://gitpod.io running a Debian container. I can't fix the chrome-sandbox issue since I don't have sudo access. The general tone here is that this is a Chrome issue and not an Electron issue, but If Electron could solve the problem wouldn't that would be a good thing?

From this site https://www.gitpod.io/blog/gitpodify/ I have seen a solution for using Puppeteer in the container.

const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});

Could Electron try some code like that if the sandbox error occurs, before killing the process? Or is this something I could invoke with a bash file?

Could Electron try some code like that if the sandbox error occurs, before killing the process? Or is this something I could invoke with a bash file?

Yeah, passing --no-sandbox argument to the electron app binary in general is supposed to work around the issue.

Depending on the installation package you could set the SUID permission bit (4755) to chrome-sandbox binary (for packages like deb, pacman, etc) or hardcode the --no-sandbox argument to the loader sh/bash script (for packages like Snap and AppImage). This is what I currently do and so there is no need to do anything for the app users (no sudo access required).

The recent electron-builder release already comes with hardcoding the --no-sandbox argument but only for the Snap package.

Thanks @vladimiry electron --no-sandbox seems to get passed the issue. I will also checkout SNAP.

there are newer electron builders, but the AppImage is still not fixed, correct?

is electron 6 is fixing the sandbox error? i am still on v4 as i cannot fix this, neither 5 or 6.

Here's the situation:

• Electron v5 enabled mixed-mode sandboxing (i.e. some processes being sandboxed and others not) on Linux. This doesn't change whether your renderer processes are sandboxed by default, but it does mean that the GPU process is now sandboxed.
• Chromium's sandbox on Linux uses an OS feature called CLONE_NEWUSER. Some kernels are built with this feature restricted to privileged users out of an abundance of caution. You can read more about it here [lwn, 2016].
• When CLONE_NEWUSER is unavailable, Chromium falls back to using a different sandboxing mechanism that requires a helper binary that is setuid to root. If this binary is not present or doesn't have the right permissions (4755 _and owned by root_), the sandbox will fail to boot.
• Setting the helper binary permissions must be done by a privileged user (i.e. root). We do not set these permissions on npm install, because we don't want to ask for root access during npm install.
• The Electron v5 release packages include the helper binary, but it is up to the various packaging and distribution tools to ensure that it gets the right permissions and ownership.

There are two workarounds:

1. Enable unprivileged access to CLONE_NEWUSER in your kernel. Some kernels support changing this with sysctl kernel.unprivileged_userns_clone=1.
2. Disable sandboxing entirely by launching with --no-sandbox. Adding this argument from JS is unfortunately insufficient, as the GPU process is launched before the main process JS is run.

We will not support automatically disabling the sandbox in Electron when these conditions are detected. You must ensure that your distributed packages to set the appropriate permissions. Most tools (at least electron-builder, electron-installer-snap, electron-installer-debian, and electron-installer-redhat) support this automatically and require no configuration from the developer. If you're using a different tool that does not support this, please raise an issue on that tool and link to this comment.

I'm closing this issue because, as mentioned in the previous paragraph, we will not be changing the requirement that Electron in production requires access to a functioning sandbox unless explicitly instructed otherwise. However, to ease development, I have opened #19550 to track the option of automatically degrading to non-sandboxed mode when Electron is installed via npm install, rather than via a distributed package.

@p3x-robot you can find a minmal example for the workaround 2. mentioned by @nornagon here which is inspired by @vladimiry

@gcascio but i can remove the snap hack right? as the snap is worked out in the electron builder, can you confirm?

@gcascio it works, thanks so much! it works!

@gcascio no workie, it generates 2 icons, so i reverted to electron v4.2.8... :(

@p3x-robot thanks for the feedback. In case you are interrested I've created an issue and will invasigate as soon as I find some time.

@nornagon so we can't even run Electron 6 on Debian and there is no way we're giving a chrome process root perms. The workarounds given are not sufficient from the user perspective.

There are two workarounds:
Enable unprivileged access to CLONE_NEWUSER in your kernel. Some kernels support changing this with sysctl kernel.unprivileged_userns_clone=1.

There is absolutely no way messing with the customers computer is the way to go about this.

Disable sandboxing entirely by launching with --no-sandbox. Adding this argument from JS is unfortunately insufficient, as the GPU process is launched before the main process JS is run.

How about adding a --sandbox flag and turn off the sandbox feature by default? This has a benefit of not screwing 99% of folks using Electron.

The workarounds given are not sufficient from the user perspective.

Using loader-like script/program which will add --no-sandbox arg can also be considered as a workaround, so no end-user actions needed. Besides such loader could test user namespace support first and add --no-sandbox only if required.

@pronebird giving the chrome-sandbox binary setuid root is much less dangerous than running Electron without a sandbox. Consider: _you're_ the one shipping the Electron binaries, so you can feel confident you're shipping trusted code (e.g. by signing it). However, if your app can be convinced to load untrusted code (possibly intentionally, e.g. by navigating to a URL on the web), then the app will happily execute that code with the user's permission, without any kind of sandbox. I'd be much more concerned about defense against attacks focused on running untrusted JS in an unsandboxed process in your app than I would be about attacks involving exploiting a bug in the same sandboxing system that Chrome uses. (And I'd expect the latter to get fixed _very quickly_ if they were discovered.) If you want to audit the code of the chrome-sandbox binary yourself, you can start here: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox.c#424

If you're committed to running without an Electron sandbox, I'd highly recommend sandboxing some other way, e.g. snapcraft or flatpak, packagers for which I believe include launcher scripts that disable Electron's sandbox inside the container.

@nornagon

giving the chrome-sandbox binary setuid root is much less dangerous than running Electron without a sandbox. Consider: you're the one shipping the Electron binaries, so you can feel confident you're shipping trusted code (e.g. by signing it). However, if your app can be convinced to load untrusted code (possibly intentionally, e.g. by navigating to a URL on the web), then the app will happily execute that code with the user's permission, without any kind of sandbox. I'd be much more concerned about defense against attacks focused on running untrusted JS in an unsandboxed process in your app than I would be about attacks involving exploiting a bug in the same sandboxing system that Chrome uses. (And I'd expect the latter to get fixed very quickly if they were discovered.)

Sure, but running a sandbox makes little sense if you have an app that never loads any remote content. I believe that has to be the case for Electron – for building desktop apps using web stack, loading maybe JSON from the web, but not like just showing web pages like we don't have Safari for that. We're past the times when folks used to wrap websites in phone-gap, aren't we?

I think the overhead is way too much. I've added a bootstrap script today into our app, and removed the chrome-sandbox binary from distribution, which was another 5 megs. Unfortunately electron-builder doesn't support any of this, so we had to add a hook and do it ourselves .

If you want to audit the code of the chrome-sandbox binary yourself, you can start here: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox.c#424

Thanks. It really depends on a threat model, and there is no way we're running anything Google with root permissions.

It can be entirely safe, but It would be also really hard to verify that all sources are intact since electron builds are shipped via npm. We'd have to set up custom build server for Electron and audit the sources ourselves. This would be a tremendous effort and I would rather avoid it.

@pronebird I'm not gonna get too involved in the sandbox discussion but my stance here is we should have the sandbox enabled by default like we currently do.

It can be entirely safe, but It would be also really hard to verify that all sources are intact since electron builds are shipped via npm

This is fundamentally incorrect, electron builds are not shipped via npm. The electron package on npm is actually about 2 files and ~40 lines of JS. The actual Electron builds are delivered via S3 and have checksums also on S3 so folks can validate that the build they are downloading is actually the build Electron shipped.

@MarshallOfSound

This is fundamentally incorrect, electron builds are not shipped via npm. The electron package on npm is actually about 2 files and ~40 lines of JS. The actual Electron builds are delivered via S3 and have checksums also on S3 so folks can validate that the build they are downloading is actually the build Electron shipped.

What I meant is, the builds are downloaded during the npm install stage. I didn't mean that they are physically hosted on npm. Let it be they are hosted on S3. Prove me wrong, but I bet that checksums are hosted on the same S3, which lowers the security grade of such system, it's one leg only. But that's not the point. Imagine the scenario where your builds are being tampered and the checksums updated accordingly. Now we have a problem. That's simply a risk and damage control on my side. No root = lower risks of something really bad happening.

@pronebird chrome-sandbox binary definitely shouldn't be 5MB, that's a bug. Opened #20049 to fix it, thanks for pointing it out.

You're certainly welcome to choose to disable sandboxing for your use case. It's unfortunate that Chromium's architecture makes it so that you have to pass --no-sandbox on the command line directly rather than calling app.commandLine.appendSwitch; ideally disabling the sandbox would be possible without necessitating a wrapper script. Hopefully with #20049 the concern of removing the binary will be ameliorated, since 200KB extra is much more reasonable to live with than 5MB.

Is there an option for using a system binary? I have reservations about giving a suid root bit to anything in my node_modules/ folder. Thanks.

@gardner you could pass --no-sandbox arg which is sort of easy workaround when you are in dev mode.

VSCode just recently switched to Electron 6 and now we are getting reports that VSCode no longer starts unless --no-sandbox option is provided. What is the way forward here? Refs: https://github.com/microsoft/vscode/issues/81056

snap is works now out of the box, for appimage, there is a hard written code:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment-517875676

the rest i do not know, i only release NPM, AppImage and SNAP...

basically, you have to re-package every type of item to add an argument (--no-sandbox) to the launcher script.

there is no solution on Electron 6 I guess, either you have to write it based on your packages or wait for a fix or downgrade...

For a better developer experience. We can set up a command as bellow within electron cli tool.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

A command like electron --ConfigSandbox.
The user will be aware and the sandbox can be easily configured.
And even when it's first run. We can ask them if they want to take the actions. y or n. And then all they need to do is enter the password. That way it will be done in a glance. And it will lead to a big user experience and win in time. Cause you'll trust the vendor or the community. And go with it. In place of searching all over the net. And that's even more valuable for the more beginners of us. And it's nice in all cases.

This issue has been closed but I am still having it with electron 7.0.0 . Is there a commit that resulted in a fix?

Why has the issue been closed? There seems to be no fix available as it still persists even in v7.0.0

Because it's a matter of packaging your app but not an issue of Electron.

Ah, alright. But how do I go about fixing this, though? Is there any way where the end user doesn't have to do any extra work?

Is there any way where the end user doesn't have to do any extra work?

Yes, there is a way, it has been discussed before.

sudo sysctl kernel.unprivileged_userns_clone=1

There's a problem with WSL users (there's plenty who use WSL) and WSL 1 doesn't use an actual linux kernal... we would have to wait for WSL2 release.

For reference regarding this limitation: https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS=y enables the user namespaces feature, but they're still restricted to privileged users by default. This suggests sysctl kernel.unprivileged_userns_clone=1

I confirm executing sudo sysctl kernel.unprivileged_userns_clone=1 is another workaround, related comment.

Yeap I use manjaro and i3wm, I took the same error but with this it's working.

Am I missing something, or is it no longer possible to simply download and run an Electron app without root access? Sorry, I hadn't realized this was specific to Debian, and that the mainline kernel doesn't even support disabling unprivileged namespaces.

Pardon my boldness, but this is absolutely insane. Electron exposes the Node.js API even in renderer processes. Using/enabling Chromium's sandbox in an Electron app is completely pointless, and as you all can see from the bug reports around GitHub pointing to this issue, it's also highly counterproductive. Please disable it if possible.

Electron exposes the Node.js API even in renderer processes.

nodeIntegration option is disabled by default since v5.

Sorry, I hadn't realized this was specific to Debian, and that the mainline kernel doesn't even support disabling unprivileged namespaces.

So running debian, I seem to be lucky that I have root access on my machine. But am I correct that this feature as it is will prevent users from running electron apps (as AppImage or not) without

a) having sudo, or
b) being able to convince someone who has sudo to enable unpriviledged namespaces?

@black-puppydog well, if they're building the app from source, they could edit the start script to pass in the --no-sandbox argument to electron. It should be possible to modify an AppImage with the same effect (by unpacking and repacking it), but I haven't tried that myself. It's also not impossible that some AppImage creators will include that flag in their builds, in which case those specific images would just work.

Otherwise, I think you're correct. Note that the mainline kernel always has unprivileged namespaces enabled, and provides no way to disable them. Hence why this is only an issue on Debian.

@black-puppydog As I recall, the installer prompts you for a root password when you first install Debian on your machine. But yes, on Debian (or any other system that uses Debian's kernel patch), you need to either have root access (via sudo or otherwise), or run Electron apps with --no-sandbox.

@ndorf In mainline Linux, user namespaces can be disabled by not compiling in the feature, but they cannot be enabled/disabled at run time or restricted to privileged processes only. Debian patches its kernels such that user namespaces are restricted to privileged processes by default, but can be enabled for all processes with a setting under /proc/sys.

The reason Debian restricts it is that unprivileged user namespaces are a serious security risk with a long history of vulnerabilities. Unprivileged user namespaces allow unprivileged processes access to a lot of kernel functionality (UID 0, capabilities, mount a file system, create a device inode, etc) that was restricted to privileged processes only for a very long time. Any kernel code relying on the assumption that unprivileged processes will never be able to do these things is vulnerable now that unprivileged processes suddenly are able to do these things.

Is there a possible workaround in the meantime until every linux distro enables those features?

See the original message:

If I chown and chmod the file then it works fine

Also see here #16631 (comment) So to make suid sandbox work you basically have to tweak the chrome-sandbox binary this way:

* `sudo chown root chrome-sandbox`

* `chmod 4755 chrome-sandbox`

The issue is more severe though if running appimage/snap packages, I have not yet revealed a decent workaround for these cases. It's working if appimage is executed with --no-sandbox arguemnt, but this is a hack.

This works if I am executing the application from the unpackaged directory. How do I package this directory after changing the permissions of chrome-sandbox ?

@shrinidhi111 4755 can be preserved when packaged, at least in the case of pacman/deb packages. The packages can also be tweaked on the specific-dist level, eg. As for the root owner, normally when the package installed from the repo on Linux the related files get root owner. In the case of AppImage build I repackage it and hardcode --no-sandbox arg in the inner AppRun script as electron-builder doesn't do that yet out from the box. Snap package is formed by electron-builder with hardcoded --no-sandbox arg (related fix added ~6 months ago).

@shrinidhi111 4755 can be preserved when packaged, at least in the case of pacman/dev packages. The packages can also be tweaked on the specific-dist level, eg. As for the root owner, normally when the package installed from the repo on Linux the related files get root owner. In the case of AppImage build I repackage it and hardcode --no-sandbox arg in the inner AppRun script as electron-builder doesn't do that yet out from the box. Snap package is formed by electron-builder with hardcoded --no-sandbox arg (related fix added ~6 months ago).

Creating snap file was an excellent idea and saved me a whole lot of work. Thanks again!

how is this still unresolved

on snap is fixed, i have my own build that works with appimage. for the rest is unresolved.

This thread is incredibly long and the error is still encountered. Is there a summary of the situation anywhere? Maybe such a summary could be linked from the error.

It sounds like https://github.com/electron/electron/issues/17972#issuecomment-495767027 and similar are proposing that it is sufficient to have electron function easily and securely only on systems with root access. Maybe it would be nice if the system detected the incorrect permissions settings and offered warnings to developers, to reduce users running into this issue, but maybe that is a separate issue. It seems also it would be nice if there were a path for users with no root access to use electron easily, with prominent understanding that untrusted resources are more dangerous than usual.

path for users with no root access to use electron easily

--no-sandbox CLI argument.

vladimiry, I was thinking of e.g. end users without much terminal experience, or running apps that wrap electron

I was thinking of e.g. end users without much terminal experience, or running apps that wrap electron

Embed that --no-sandbox to app shortcut. Any Linux package here will be working well regardless of kernel.unprivileged_userns_clone system value. So it's a matter of packaging the application.

That's true if I'm a developer, and make a suitable warning for my end users. Won't many developers never learn about this issue due to the namespace sandbox working for them? It's also worrisome that existing solutions are in place without communicating to people involved that untrusted resources are more dangerous.

This solution only work when you get this error because of WSL

I ran into this issue while trying to use electron on WSL (WSL2 on my case).
Even by using an X11 server, electron was not able to run over X11.

I had to build electron for Windows, even if I run it inside WSL. After that, everything work as excepted
The simplest way to do that:

• Uninstall electron npm uninstall electron
• Change npm config platform export npm_config_platform=win32
• Install electron npm install electron
• Unset the environment variable unset npm_config_platform

This suggests sysctl kernel.unprivileged_userns_clone=1

I see this issue with WSL (Windows 10), Ubuntu 18.04 installed into WSL.
sudo sysctl kernel.unprivileged_userns_clone=1 does not work.

sudo sysctl kernel.unprivileged_userns_clone=1
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory

Using chown and chmod is also not an option.

@MarshallOfSound zip does not support permissions, but ultimately the issue is not the chmod permission, but rather the owner. The setuid sandbox helper is suid _to root_, because it needs to perform functions that are only available to root. If it were possible to set the appropriate permissions without first gaining root privileges, that would be a very serious vulnerability in Linux. Fortunately for Linux, and unfortunately for us, that is not the case.

zip _does_ support permissions on unix-based systems (or at least on the variants of linux I've tested). See https://serverfault.com/a/585889/17620

The permission bits are stored in the zip's central-directory's file-header suffix. The suffix's externalFileAttributes field can be used to store the permissions bits for each file/directory entry.

cc @MarshallOfSound

i have the same problem !

[gxz@localhost build]$ ./Electron-0.1.1.AppImage 
[23154:0521/155029.728314:FATAL:setuid_sandbox_host.cc(157)] 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-E0wZecV/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap(吐核)
[gxz@localhost build]$ sudo ./Electron-0.1.1.AppImage 
[sudo] gxz 的密码：
[23191:0521/155048.067790:FATAL:electron_main_delegate.cc(211)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
Trace/breakpoint trap
[gxz@localhost build]$ 

run as normal user , has error: FATAL:setuid_sandbox_host.cc(157)]。run as root , has error: FATAL:electron_main_delegate.cc(211)]

but when i yum install snap after， run as root or normal user is ok。

sudo chown root chrome-sandbox
sudo chmod 4755 chrome-sandbox

This works well.

@cuixiping it works :+1:

I did

$ find . -name chrome-sandbox
./node_modules/electron/dist/chrome-sandbox

$ sudo chown root ./node_modules/electron/dist/chrome-sandbox

$ sudo chmod 4755 ./node_modules/electron/dist/chrome-sandbox

I had the same issue when I ran electron on Deepin and I have resolved the problem with this code
electron . --no-sandbox

hope you that helps you

doesnt work

@fabiospampinato your adaptation disables the sandbox for all Linux package types but at least DEB and Pacman packages work well with SUID sandbox (probably all the not container-like packages), there is just a need to set SUID permission bit to chrome-sandbox binary. But don't set SUID permission bit for Snap package as Snap Store rejects such kinds of packages. So I set SUID bit for all the Linux packages expect Snap/AppImage packages which get disabled sandboxing, related code.

Hi @vladimiry
I could not access the link you have attached here. Can you help with that?
Additionally, were you able to figure out how to do --no-sandbox in electron-builder after-pack script?

Thanks

@tushar-compro, here it's https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. Basically I set 4755 bit in after-pack script for some package types and still repacking the appimage+snap packages. Actually the electron-builder have already embedded --no-sandbox arg into snap but not yet in appimage https://github.com/electron-userland/electron-builder/pull/4496. Buy the way, these days electron-builder already sets 4755 bit https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl#L7. So recent electron-builder version should simplify things for most developers.

@vladimiry
Am I right in understanding that you have set the 4755 bit for targets OTHER THAN appimage and snap.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

But the problem is occurring while using .appimage installer on debian distro.

Am I missing something here?

But the problem is occurring while using .appimage installer on debian distro.

As I said the appimage still requires special treatment. I repackage it and embed the --no-sandbox into the ./AppRun script. Locate the DISABLE_SANDBOX_ARGS_LINE keyword here https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

But the problem is occurring while using .appimage installer on debian distro.

As I said the appimage still requires special treatment. I repackage it and embed the --no-sandbox into the ./AppRun script. Locate the DISABLE_SANDBOX_ARGS_LINE keyword here https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

the latest electron builder takes care of the no sanbox argument automatically in both snap and appimage.

@vladimiry
So, am I right to understand that 4755 bit setting you have done is for installers other than appimage and snap. And for appimage you have set no-sandbox. Can you please confirm.

@p3x-robot
yes. you're partially right.

1. Latest electron-builder sets no-sandbox for snap but NOT for appimage. However, they have set 4755 bit for appimage.
2. In my project I'm using electron-version 20.x.x. Updating it to 22.x.x will be an effort in itself. Just trying to avoid that if possible. Updating to v22 will be last resort.

the latest electron builder takes care of the no sanbox argument automatically in both snap and appimage.

Could not yet locate in their code the appimage-specific snippet similar to this one applied for snaps (https://github.com/electron-userland/electron-builder/pull/4496 still open). Anyway in my case repacking still required since I put there addition args, other than sanbox-related.

So, am I right to understand that 4755 bit setting you have done is for installers other than appimage and snap. And for appimage you have set no-sandbox. Can you please confirm.

Correct. But modern electron builder sets 4755 internally. I check though that it's not set for snap/appimage since that would be a mistake. For example snap won't start with 4755 bit set to electron binary if I remember things correctly.

@vladimiry
I just need to set no-sandbox as my appimages are not working in debian.

I believe I won't need repacking in this case. But I could not find the right documentation of electron builder for doing that. Or do you think I'll also need repacking?

Can you point me to the right documentation which can help me in how to do that.

Additionally, I understand that I have both the options either setting 4755 bit or setting no-sandbox.
Which one do you think is better?

Additionally, I understand that I have both the options either setting 4755 bit or setting no-sandbox.

If I remember things correctly, settings 4755 to appimage won't solve the issue. You need to (one of):

• start your appimage file with --no-sandbox command line arg
• have --no-sandbox embedded into the ./AppRun script located in your appimage file (so repackaging needed).

Can you point me to the right documentation which can help me in how to do that.

I doubt you will find detailed information about the issue in any documentation. I'm not aware of any relevant docs.

Additionally, I understand that I have both the options either setting 4755 bit or setting no-sandbox.

If I remember things correctly, settings 4755 to appimage won't solve the issue. You need to (one of):

• start it with --no-sandbox command line arg
• have --no-sandbox embedded into the ./AppRun script located in your appiamge file (so repackaging needed).

Can you point me to the right documentation which can help me in how to do that.

I doubt you will find detailed information about the issue in any documentation. I'm not aware of any relevant docs.

electron builder latest embeds the --no-sandbox in the ./AppRun, i used to re-package, but now it is useless, i just use the native electron builder.

@vladimiry
yes. setting 4755 alone won't work. With 4755 we need to change the owner of chrome-sandbox to root.
Anyways, thanks a lot for your help. I'll try to refer your code and set the no-sandbox then.

@p3x-robot
Can you please share some link (electron-builder repo) where we can see the code doing this.

https://github.com/patrikx3/onenote

@vladimiry
yes. setting 4755 alone won't work. With 4755 we need to change the owner of chrome-sandbox to root.
Anyways, thanks a lot for your help. I'll try to refer your code and set the no-sandbox then.

@p3x-robot
Can you please share some link (electron-builder repo) where we can see the code doing this.

https://github.com/patrikx3/onenote

electron builder latest embeds the --no-sandbox in the ./AppRun, i used to re-package, but now it is useless, i just use the native electron builder.

I just tested it using recent electron builder version and it doesn't embed the --no-sandbox in the ./AppRun sh script. If you start the appimage it fails with known [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found -like error. Maybe you have got the kernel.unprivileged_userns_clone flag enabled on your system. If so try disabling it like sudo sysctl kernel.unprivileged_userns_clone=0 and starting the appimage file again.

electron builder latest embeds the --no-sandbox in the ./AppRun, i used to re-package, but now it is useless, i just use the native electron builder.

I just tested it using recent electron builder version and it doesn't embed the --no-sandbox in the ./AppRun sh script. If you start the appimage it fails with known [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found -like error. Maybe you have got the kernel.unprivileged_userns_clone flag enabled on your system. If so try disabling it like sudo sysctl kernel.unprivileged_userns_clone=0 and starting the appimage file again.

weird, there are 10k snap installations with the latest electron builder. and definately the electron builder is shows that it adds that flag ...

there are 10k snap

We are talking about appimage, not the snap thing. Snap of course has the arg embedded as I referenced above, here https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197-L202.

there are 10k snap

We are talking about appimage, not the snap thing. Snap of course has the arg embedded as I referenced above, here https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197-L202.

you are right. i was thinking for some reason it was done in appimage, i even removed the code for the re-package and add no-sandbox, but i tried again and i see it is missing, so i added my revert of my build, no it works. sorry, in my corifeus-builder, you can see what i am doing: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Hi @nornagon considering how common this issue is, can the official electron quick-start tutorial be updated to include the work-around so newbies have a positive experience?

Edit: Thanks to community encouragement I have opened a FR #26478

@gabefair That seems like a reasonable proposal. Would you be interested in opening a PR?