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

[charlag]

Electron requires sandboxing now.
Non-paranoid distributions enable non-privileged containers but Debian does not. App tries to fall back to fall back to the included helper binary but this binary must have setuid root.

It's not clear if we can fix that, at least with AppImage. Maybe we should at least document that and --no-sandbox option.

see electron/electron#17972
see electron/electron#17972 (comment)

[mpfau]

Happens on Debian buster.

Add the following to /etc/sysctl.conf as workaround:
kernel.unprivileged_userns_clone=1

[CrossBound]

I am experiencing this problem on Debian 10 (Buster). I initially downloaded the file, granted execute permissions, and it did nothing... no warning or error. After running on the command line I realized an error was being thrown.

[4438:1122/230838.647104: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_tutano0dGmEB/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

using the --no-sandbox option is not a good option in my opinion as it eliminates the ability to easily run without having to drop to the command line just to open the tutanota app.

[vladimiry]

For the AppImage package the --no-sandbox needs to be hardcoded into the inner AppRun script so you don't have to explicitly pass it as CLI arg (same as for the Snap package). Here is an example of the script that does needed preprocessing during the app bundling stage.

[charlag]

Sorry, closed it by accident.

We don't want to disable sandbox for everyone.

[vladimiry]

Containerized package types (like Snap or AppImage) come with isolation capabilities which as far as I know makes it difficult to work well with built-in electron/chromium sandboxing. Advanced users could try firejail sandboxing utility that is supposed to work well with AppImage.

[charlag]

@vladimiry I believe there's misunderstanding of sandboxing options. The sandbox which Electron uses is for sandboxing the renderer process from the main process. see https://electronjs.org/docs/api/sandbox-option
The sandboxing which Snap/Flatpak uses is another thing (it can limit which folders the app can access e.g.) and I don't know about AppImage sandboxing anything.

[vladimiry]

I don't know about AppImage sandboxing anything.

I didn't use sandboxing term but isolation capabilities. Regarding sandboxing, firejail is mentioned there.

[ghost]

Just also want to confirm this bug on Debian 10 (Buster):

[2111:1223/094824.159565: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_tutanoHpzPs6/chrome-sandbox is owned by root and has mode 4755.

The workaround:

kernel.unprivileged_userns_clone=1

Mentioned by @mpfau gets you up and running again. Would prefer another way if possible, but thanks for this!

[lagerimsi-ds]

Does it really solve the problem or make them more: Enable these privileges for the whole system.
I mean: it's not just one app I decide to enable but anything that comes along like this.

https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do

[abrahamparayil]

I can confirm this issue on my Debian Buster setup too.

Also enabling those privileges for the whole system is a very bad idea. It is configured so in Debian so as prevent the vulnerabilities that arise by enabling it. There is however a way to edit the tutanota-desktop.desktop file in ~/.local/share/applications folder and hardcode the --no-sandbox option there.

Hopefully, when the team makes the source code of the desktop available we can package it for various distributions.

[mucahitkurtlar]

I have this problem on my Debian GNU/Lİnux with KDE Plasma machine.
The solution is for KDE Plasma users:
Right click "Tutanota Desktop" app > "Edit Application" > "Application" tab > Add ' --no-sandbox' to Command area > "OK"

[puzzledbycode]

using the --no-sandbox option is not a good option in my opinion as it eliminates the ability to easily run without having to drop to the command line just to open the tutanota app.

A way to avoid using the command line is to create a desktop launcher. This depends a bit on the desktop environmend you are using, but on most that support it, it should work somewhat like this:

• Right click on an empty space on the desktop.
• Choose "Create a new launcher here" (or something similar)
• a window opens where you have a field for the name of the launcher and one for the command
• as command you use the full path of the AppImage plus --no-sandbox, it will look somewhat like this:
  /home/usersname/folder/tutanota-desktop-linux.AppImage --no-sandbox

Normally you can assign an Icon for the launcher also, not sure if there is a way to use the original Tutanota Icon, but that seems of little importance to me. At least this is a very simple way to not have to use the command line.

[vladimiry]

By the way, electron-builder has recently merged the electron-userland/electron-builder#4496 PR so it will produce the appimage files with --no-sandbox embedded into the AppRun script.

[zarathustra-f90]

Thanks for the helpful info you all provided. I run all my appimages now with --no-sandbox option, however, does this enable a "security hole"? Sorry about the nomenclature but i'm not too savvy about the electron stuff, i was wondering because root privileges were mentioned in other comments.

[danmanrana]

@avronr I thought basically all Tutanota's code was open-source. Anyways, I still need that --no-sandbox argument for it to open, so I guess the merge that @vladimiry mentioned doesn't apply to Debian.

[antonlydell]

I have the same issue aswell on Ubuntu 24.04. It seems similar to this issue in Bitwarden :

Please stop packaging the Desktop client with a setuid root chrome-sandbox

Is it a secure workaround?

[charlag]

installing fuse is the right solution

[charlag]

see electron-userland/electron-builder#8686

I would wait a bit if electron-builder does it, otherwise we can just repackage appimage like @Samueru-sama did in the linked PR

[Samueru-sama]

see electron-userland/electron-builder#8686

I would wait a bit if electron-builder does it, otherwise we can just repackage appimage like @Samueru-sama did in the linked PR

Hey installing fuse will not fix this issue. The issue and PR I was talking about were to fix the libfuse2 dependency of AppImages.

This issue is about namespaces being disabled, which is just a disgrace of linux in general, this is a feature of the kernel and kernel devs have rejected the patches that allow for this to be disable over and over but hasn't stopped distros doing it anyway...

Many electron apps just instead add --no-sandbox to the AppRun but this is also a bad idea, at the very least some check like unshare --user -p /bin/true should be done to test if there is access to namespaces and if not then --no-sandbox is used and a big warning is given about it.

[charlag]

@Samueru-sama thank you for chipping in. I hope that electron-builder will switch to a statically linked runtime soon but I'm not holding my breath.

The problem with big warnings is that they are completely not actionable for users. In this case this is even worse than secret storage (that is also lacking in many installations) which we run into similar situation with.