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

[christianbundy]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  • 5.0.0
• Operating System:
  • Arch Linux x64
• Last Known Working Electron version::
  • 4.1.5

Expected Behavior

Running node_modules/.bin/electron --version should output v5.0.0.

To be clear, all commands create this error, but I'm using the --version flag for simplicity.

Actual Behavior

$ node_modules/.bin/electron --version
[2720:0425/142001.775056: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 /home/christianbundy/src/ssbc/patchwork/node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.

Additional Information

$ stat /home/christianbundy/src/ssbc/patchwork/node_modules/electron/dist/chrome-sandbox
  Size: 5185424   	Blocks: 10128      IO Block: 4096   regular file
Device: 802h/2050d	Inode: 1465270     Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/christianbundy)   Gid: ( 1000/christianbundy)
Access: 2019-04-25 14:15:10.609279524 -0700
Modify: 2019-04-25 14:15:10.659278929 -0700
Change: 2019-04-25 14:15:10.659278929 -0700
 Birth: 2019-04-25 14:15:10.609279524 -0700

If I chown and chmod the file then it works fine, but my intuition is that npm install electron@latest should work without those commands. Is this expected behavior?

[nornagon]

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 electron-userland/electron-installer-debian#184 and electron-userland/electron-installer-redhat#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.

[christianbundy]

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!

[nornagon]

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

[kitingChris]

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

[MarshallOfSound]

@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.

[vladimiry]

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.

[vladimiry]

@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.

[vladimiry]

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.

[burningTyger]

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

[vladimiry]

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

[MarshallOfSound]

@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?

[liberodark]

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

[nornagon]

@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.

[vladimiry]

As for now, I like more the first option.

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.

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.

3. 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.

4. 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).

[nornagon]

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.

[vladimiry]

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.

[vladimiry]

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.

[p3x-robot]

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.

[tushar-compro]

@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.

[vladimiry]

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 (electron-userland/electron-builder#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.

[tushar-compro]

@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?

[vladimiry]

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.

[p3x-robot]

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.

[tushar-compro]

@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.

[p3x-robot]

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

[vladimiry]

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.

[p3x-robot]

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 ...

[vladimiry]

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.

[p3x-robot]

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

[gabefair]

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

[nornagon]

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