"SUID sandbox helper binary" warning on debian 10

[masx200]

Describe the bug

Unable to run the program GitHubDesktop.

[6028:0303/110012.970291: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/ma/GitHubDesktop-linux-2.3.1-linux1.deb/data/opt/GitHub Desktop/chrome-sandbox is owned by root and has mode 4755.
追踪与中断点陷阱
Trace and breakpoint traps

Version & OS

GitHubDesktop-linux-2.3.1-linux1.deb

Linux ma-pc 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

Debian GNU/Linux 10 (buster)

Steps to reproduce the behavior

github-desktop

Expected behavior

A clear and concise description of what you expected to happen.

Actual behavior

A clear and concise description of what actually happened.

Screenshots

Add screenshots to help explain your problem, if applicable.

Logs

Attach your logs by opening the Help menu and selecting Show Logs..., if applicable.

Additional context

Add any other context about the problem here.

[quizilkend]

Happens to me as well.
If the permission are changed according to the error message github desktop aborts anyway.

Happens with the appimage as well.

./github-desktop.AppImage [24186:0319/111744.233413: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_githubGt9pWR/chrome-sandbox is owned by root and has mode 4755. fish: “./github-desktop.AppImage” terminated by signal SIGTRAP (Verfolgungs- oder Haltepunkt erreicht)

[StygianBlues]

If one is okay with with the possible risks, as temporary workaround:

sudo sysctl kernel.unprivileged_userns_clone=1

Or to make the change survive reboot add kernel.unprivileged_userns_clone=1 to /etc/sysctl.conf (or /etc/sysctl.d ) and run sudo sysctl --system

[quizilkend]

I just read about that, and I'm not okay with the additional risks.
Hopefully there will be another solution to this issue.

[shiftkey]

Looks like there's a packaging change that I need to make, based on electron/electron#17972

@quizilkend @StygianBlues can you share what the permissions are for /opt/GitHub Desktop/chrome-sandbox on your machine as I'm not seeing the same problem with 2.4.0-linux1 which suggests it might have been resolved.

[StygianBlues]

Permissions on my /opt/GitHub Desktop/chrome-sandbox file are 755 (rwxr-xr-x). My machine's kernel: 5.4.0-4-rt-amd64 #1 SMP PREEMPT_RT Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux.

Thank you for all the work you do in keeping this available on Linux.

[shiftkey]

Actually, this comment from inside the electron-installer-helper package here seems important:

/**
   * For Electron versions that support the setuid sandbox on Linux, changes the permissions of
   * the `chrome-sandbox` executable as appropriate.
   *
   * The sandbox helper executable must have the setuid (`+s` / `0o4000`) bit set.
   *
   * This doesn't work on Windows because you can't set that bit there.
   *
   * See: https://github.com/electron/electron/pull/17269#issuecomment-470671914
   */

I believe this would change the permission to -rwsr-xr-x (note the s instead of x for the owner), and that's not present in the latest version either.

[jfgordon2]

Just downloaded Debian 10 (GNOME) and tested @Q-codes:

sudo chown root /the/path/to/chrome-sanbox
sudo chmod 4755 /the/path/to/chrome-sanbox

I unfortunately got a Trace/breakpoint trap error

Adding the following command afterwards worked for me:

sudo sysctl kernel.unprivileged_userns_clone=1

[shiftkey]

@jfgordon2 I was hoping the change to chmod/chown was all that was needed, but I guess Debian hardening their setup is still an issue.

[shiftkey]

Out of curiosity, is anyone able to get this to work wiht the --no-sandbox flag, e.g:

# ensure hardened setting is enabled
sudo sysctl kernel.unprivileged_userns_clone=0
/usr/bin/github-desktop --no-sandbox

I've found some other threads that seem to suggest this works, e.g signalapp/Signal-Desktop#3536 (comment), but it's still not a great solution.

[jfgordon2]

@shiftkey I looked through the electron-builder-debian package for how they resolved this issue, and it looks like they just do the chmod. A few other electron apps have just appended the --no-sandbox but that seems like it might cause some broader security concerns.

Ubuntu seems to enable unprivileged_userns_clone in the kernel, effectively undoing what debian adds by default.

[jfgordon2]

Out of curiosity, is anyone able to get this to work wiht the --no-sandbox flag, e.g:

# ensure hardened setting is enabled
sudo sysctl kernel.unprivileged_userns_clone=0
/usr/bin/github-desktop --no-sandbox

I've found some other threads that seem to suggest this works, e.g signalapp/Signal-Desktop#3536 (comment), but it's still not a great solution.

Can confirm, no sandbox works with that kernel option disabled on debian 10

[shiftkey]

I've opened #254 to track the file mode change so please follow along with that PR.

@jfgordon2 the user owning chrome-sandbox should already be root on install, so a chown here shouldn't be necessary, right?

[jfgordon2]

I've opened #254 to track the file mode change so please follow along with that PR.

@jfgordon2 the user owning chrome-sandbox should already be root on install, so a chown here shouldn't be necessary, right?

Correct

[midnqp]

The problem with chrome-sandbox is actually prevalent in a few other cases; like Min Browser -- the exact same error, which was solved by chown and chmod. And then Min could be lauched from Desktop etc. swiftly.

[shiftkey]

@Q-codes it's not clear to me that we've got the full fix given the kernel.unprivileged_userns_clone warning that still appears after doing the chmod/chown changes - what are we missing?

[shiftkey]

Unassigning myself for now because 2.4.1 RC1 contains the chmod change, which should make the message go away (for deb and AppImage, rpm already had this fix).

The kernel.unprivileged_userns_clone setting doesn't have an easy fix, because warning the user on launch is challenging for different reasons:

• we might be able to warn when launching from command line, but we're limited to making changes to the main process scripts that github-desktop (which is just a rebranded electron executable) launches - that might not be early enough in the application lifecycle to handle this
• github command line shortcut would only apply to debian installs
• if the user launches from the .desktop file, can we show any sort of UI before chrome-sandbox runs and raises an exception?

The latter would be ideal (catching all cases) if we can find a way to show some UI that won't crash, but it would require more integration into the codebase itself...

[ghost]

Unassigning myself for now because 2.4.1 RC1 contains the chmod change, which should make the message go away (for deb and AppImage, rpm already had this fix).

Just tried GitHubDesktop-linux-2.4.1-linux1.AppImage under Debian 10 — still failed:

$ ./GitHubDesktop-linux-2.4.1-linux1.AppImage
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
Trace/breakpoint trap

[shiftkey]

@Symbian9 oops, I guess AppImage isn't installed as root so that's still a problem there.

[ghost]

I guess AppImage isn't installed as root

I want use GitHub-*.AppImage without install (no need install as AppImage is portable) run it as root.

Is it possible?

[shiftkey]

@Symbian9 I'm honestly not sure - it's been at least a year since I looked at anything related to AppImage

[ghost]

As I remember I no need to launch GitHubDesktop-*.AppImage under root for GitHubDesktop < 2.3.x.

[shiftkey]

@Symbian9 this might be related to the chrome-sandbox changes that came from upgrading the app from Electron 5 to 7 - this was part of 2.4.0 and the fact that you also see the Trace/breakpoint trap error here makes me think this is the same underlying issue.

[shiftkey]

After building Electron from source and slipstreaming it into the current GitHub Desktop app I was able to trigger the Trace/breakpoint trap which now has the backtrace for where it is getting stuck:

Starting program: /usr/bin/github-desktop 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe8810700 (LWP 93491)]

Thread 1 "github-desktop" received signal SIGTRAP, Trace/breakpoint trap.
0x000055555a099364 in service_manager::ZygoteHostImpl::LaunchZygote(base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*, std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >)::$_3::operator()() const (this=<optimized out>)
    at ../../services/service_manager/zygote/host/zygote_host_impl_linux.cc:186
186	../../services/service_manager/zygote/host/zygote_host_impl_linux.cc: No such file or directory.
(gdb) backtrace
#0  0x000055555a099364 in service_manager::ZygoteHostImpl::LaunchZygote(base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*, std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >)::$_3::operator()() const (this=<optimized out>)
    at ../../services/service_manager/zygote/host/zygote_host_impl_linux.cc:186
#1  0x000055555a099364 in service_manager::ZygoteHostImpl::LaunchZygote(base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*, std::__1::vector<std::__1::pair<int, int>, std::__1::allocator<std::__1::pair<int, int> > >) (this=<optimized out>, cmd_line=<optimized out>, control_fd=<optimized out>, additional_remapped_fds=...) at ../../services/service_manager/zygote/host/zygote_host_impl_linux.cc:186
#2  0x00005555582e78e8 in content::(anonymous namespace)::LaunchZygoteHelper(base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*) (cmd_line=0x7fffffffd6a0, control_fd=0x0) at ../../content/app/content_main_runner_impl.cc:287
#3  0x000055555a09837e in base::OnceCallback<int (base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*)>::Run(base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*) && (this=0x7fffffffd898, args=0x7fffffffd6a0, args=0x197ae507f7e0) at ../../base/callback.h:98
#4  0x000055555a09837e in service_manager::ZygoteCommunication::Init(base::OnceCallback<int (base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*)>) (this=0x197ae507f7e0, launcher=...) at ../../services/service_manager/zygote/host/zygote_communication_linux.cc:250
#5  0x000055555a09e081 in service_manager::CreateGenericZygote(base::OnceCallback<int (base::CommandLine*, base::ScopedGeneric<int, base::internal::ScopedFDCloseTraits>*)>) (launcher=...) at ../../services/service_manager/zygote/host/zygote_handle_linux.cc:21
#6  0x00005555582e70c1 in content::(anonymous namespace)::InitializeZygoteSandboxForBrowserProcess(base::CommandLine const&) (parsed_command_line=...)
    at ../../content/app/content_main_runner_impl.cc:311
#7  0x00005555582e70c1 in content::ContentMainRunnerImpl::Initialize(content::ContentMainParams const&) (this=<optimized out>, params=...)
    at ../../content/app/content_main_runner_impl.cc:831
#8  0x000055555a09e79d in service_manager::Main(service_manager::MainParams const&) (params=...) at ../../services/service_manager/embedder/main.cc:367
#9  0x00005555575ba441 in content::ContentMain(content::ContentMainParams const&) (params=...) at ../../content/app/content_main.cc:19
#10 0x0000555556b8b27b in main(int, char**) (argc=1, argv=0x7fffffffdfe8) at ../../electron/shell/app/atom_main.cc:189
(gdb) 

I can't spot anything obviously wrong here, but if you want to spelunk the source here I recommend entering the file into https://source.chromium.org/

[shiftkey]

This Zygote documentation is probably important: https://source.chromium.org/chromium/chromium/src/+/master:docs/linux/zygote.md;l=16?q=zygote&ss=chromium%2Fchromium%2Fsrc

[shiftkey]

So I think I've stumbled into the root cause of problem, and it's part of Chromium itself electron/electron#21309

Electron's fallback sandbox crashes on a Linux system with user namespaces disabled like Debian 10 and located in a path that contains spaces. I guess that this is an Electron issue because the issue is not reproducible with a path without spaces.
...
I think this is an issue in Chromium as well. The code at //sandbox/linux/suid/client/setuid_sandbox_host.cc calls base::CommandLine::PrependWrapper, which splits on whitespace.

I also observe this issue to be present when installing Chrome itself into a directory containing a space.

Two options:

• wait on an upstream patch to Chromium, which makes it into an Electron release, which is then pulled into Desktop (timeline unclear)
• figure out a way to change the debian installer so that it outputs to /opt/github-desktop/ rather than /opt/GitHub Desktop/

EDIT: not sure what the fix looks like for the AppImage, unless that too is generating a parent directory containing spaces.

EDIT 2: i've confirmed moving the app from /opt/GitHub Desktop/ to /opt/github-desktop is all that's needed to get it working, without any changes to Electron

[jfgordon2]

@shiftkey I was taking a look at the electron-builder script, and it seems like the path name is dependent on the product name in the package.json file

• LinuxTargetHelper.ts

The productFilename variable is just a sanitized productName:

• appInfo.ts

Which would mean that you can do some creative things like:

1. Update the app/package.json file to use a name without a space, then
2. Update the script/electron-builder-linux.yml to include a desktop key so that GitHub Desktop is still presented to the end-user

Or I guess you could do some changes to the electron-builder to "sanitize" differently.

[shiftkey]

1. Update the app/package.json file to use a name without a space, then
2. Update the script/electron-builder-linux.yml to include a desktop key so that GitHub Desktop is still presented to the end-user

Step 1 was how it was originally configured (you can override productName in electron-builder config), but I think we had issues with the generate .desktop file using this new value and the app appearing as GitHubDesktop when you search for it. Step 2 would improve this, but I think the last time I tried this I wasn't happy with the duplication of things that were in app/package.json.

I've been planning to move away from electron-builder for a while for many reasons (which I'll elaborate on in the next PR), so I'm gonna use #262 as an opportunity to see if electron-installer-debian is easier to use, and extract that from the electron-builder config.

I've tested electron-installer-debian and it appears to be installing into /usr/lib/github-desktop/ by default without any config changes, which is precisely what we want.

[eugeniocarvalho]

Just downloaded Debian 10 (GNOME) and tested @Q-codes:

sudo chown root /the/path/to/chrome-sanbox
sudo chmod 4755 /the/path/to/chrome-sanbox

I unfortunately got a Trace/breakpoint trap error

Adding the following command afterwards worked for me:

sudo sysctl kernel.unprivileged_userns_clone=1

I did what jfgordon2 said and it worked

[shiftkey]

I've published 2.4.1-linux2 which contains a new Debian package that should address this problem.

@Symbian9 I see you encountered a similar problem with the AppImage installer - could you open a fresh issue to provide details about your setup and what the installer is doing (or not doing) so we can focus fresh on that?

[ghost]

with the AppImage installer

Could you point me? I'm not sure what you mean under "AppImage installer", especially "installer" term.

[shiftkey]

@Symbian9 I'm referring to this comment: #222 (comment)

[probonopd]

This is how I had dealt with this annoying Electron/Debian/AppImage issue in another project:

https://github.com/probonopd/nativefier-test/blob/e38bc4b39def3c27046de512e24a220bb9c3ced2/nativefier.bash#L41-L52

I'd be happy to hear whether there are better solutions.

[shiftkey]

@probonopd there were two issues I found:

• the file mode for chrome-sandbox wasn't set correctly when unpacking the Electron distribution (we chmod 4755 the file now before packaging)
• having kernel.unprivileged_userns_clone=0 and installing to a path containing spaces will trigger the Chromium issue Crash due to SUID sandbox helper binary in paths with spaces electron/electron#21309 https://bugs.chromium.org/p/chromium/issues/detail?id=1029290

Given the AppImage can be run from anywhere, we might not be able to fix the latter if users run it from a directory with spaces in the path. But I wanted to first confirm we haven't also fixed this for AppImage...

[probonopd]

Given the AppImage can be run from anywhere, we might not be able to fix the latter if users run it from a directory with spaces in the path.

Thanks @shiftkey. An AppImage, when executed, gets mounted at a temporary mountpoint in /tmp/.mount.... Then AppRun is executed from there. So as long as the user doesn't unpack the AppImage, the path from which the payload application is executed will not have spaces in it even though the path at which the AppImage is stored does.

the file mode for chrome-sandbox wasn't set correctly when unpacking the Electron distribution (we chmod 4755 the file now before packaging)

Are you saying that doing this will remove the need for kernel.unprivileged_userns_clone=0?

[shiftkey]

@probonopd

So as long as the user doesn't unpack the AppImage, the path from which the payload application is executed will not have spaces in it even though the path at which the AppImage is stored does.

Good to know. Then it may just be the file mode issue that actually affected the AppImage and we've conflated the two problems because they both mention chrome-sandbox and "SUID sandbox helper binary".

Are you saying that doing this will remove the need for kernel.unprivileged_userns_clone=0?

I believe so, based on this comment that also mentioned the AppImage from @quizilkend:

Happens with the appimage as well.

./github-desktop.AppImage [24186:0319/111744.233413: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_githubGt9pWR/chrome-sandbox is owned by root and has mode 4755. fish: “./github-desktop.AppImage” terminated by signal SIGTRAP (Verfolgungs- oder Haltepunkt erreicht)

[probonopd]

Some experimentation:

me@host:~$ sudo sysctl kernel.unprivileged_userns_clone=0
kernel.unprivileged_userns_clone = 0

me@host:~$ Downloads/GitHubDesktop-linux-2.4.1-linux2.AppImage 
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
Trace/breakpoint trap

me@host:~$ Downloads/GitHubDesktop-linux-2.4.1-linux2.AppImage --appimage-extract

me@host:~$ squashfs-root/AppRun 
[15983:0502/162658.525200: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/me/squashfs-root/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap

me@host:~$ sudo ls -lh squashfs-root/chrome-sandbox 
-rwsr-xr-x 1 me me 5.4M May  2 16:26 squashfs-root/chrome-sandbox

# Set permissions as indicated above
me@host:~$ sudo chown root:root squashfs-root/chrome-sandbox
me@host:~$ sudo chmod 4755 squashfs-root/chrome-sandbox 
me@host:~$ sudo chmod 755 squashfs-root/

me@host:~$ squashfs-root/AppRun 
# Runs without the error!

# Repack as an AppImage
VERSION=2.4.1 /isodevice/Applications/appimagetool-482-x86_64.AppImage squashfs-root/

# As an AppImage, the 4755 is without effect since FUSE does not allow setuid
me@host:~$ ./GitHub_Desktop-2.4.1-x86_64.AppImage 
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
Trace/breakpoint trap

I don't know whether it would be possible (or desirable) to change something in FUSE so that it honors the setuid bit.

[shiftkey]

# As an AppImage, the 4755 is without effect since FUSE does not allow setuid

Oof, that's rough. Thanks for digging in @probonopd!