SUID sandbox helper binary issue on Debian Linux

[xuhdev]

On Debian 10, starting agent using either the released AppImage or npm run electron, the following error message will show up, and the app either doesn't start up or start up and do nothing (i.e., no configuration can be read from or written to keyboard):

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_UHK.ApsWHdpE/chrome-sandbox is owned by root and has mode 4755.

Run the following in the source tree (as suggested in electron/electron#17972 (comment)) and then npm run electron will succeed without error:

sudo chown root node_modules/electron/dist/chrome-sandbox
sudo chmod 4755 node_modules/electron/dist/chrome-sandbox

[mondalaci]

Thanks for your report! It's strange that only Debian seems to be affected so far. Can you test it with multiple Debian computers and also Agent 1.2.13 and 1.2.12?

[xuhdev]

@mondalaci Interestingly, agent 1.2.12 works properly on my system, while 1.2.13 doesn't.

[xuhdev]

I checked out v1.2.12 but npm install didn't succeed because there was a failure to build node-hid:

prebuild-install WARN install No prebuilt binaries found (target=12.10.0 runtime=node arch=x64 platform=linux)
make: Entering directory '/home/hong/src/agent/node_modules/node-hid/build'
  CC(target) Release/obj.target/hidapi/hidapi/linux/hid.o
  AR(target) Release/obj.target/hidapi.a
  COPY Release/hidapi.a
  CXX(target) Release/obj.target/HID/src/HID.o
In file included from ../../nan/nan_converters.h:67,
                 from ../../nan/nan.h:221,
                 from ../src/HID.cc:31:
../../nan/nan_converters_43_inl.h: In static member function ‘static Nan::imp::ToFactoryBase<v8::Boolean>::return_t Nan::imp::ToFactory<v8::Boolean>::convert(v8::Local<v8::Value>)’:
../../nan/nan_converters_43_inl.h:18:51: warning: ‘v8::MaybeLocal<v8::Boolean> v8::Value::ToBoolean(v8::Local<v8::Context>) const’ is deprecated: ToBoolean can never throw. Use Local version
. [-Wdeprecated-declarations]
       val->To ## TYPE(isolate->GetCurrentContext())                            \
                                                   ^
../../nan/nan_converters_43_inl.h:22:1: note: in expansion of macro ‘X’
 X(Boolean)

But if we read the error message it sort of makes sense because a regular user cannot change the ownership to root and permission to 4755. I'm not sure though; maybe the best solution is to repackage the AppImage following the suggestion by the error message in the OP and make a document change.

[mondalaci]

I'm not sure why node-hid fails to build at your side. It's quite strange that 1.2.12 works on your system while 1.2.13 doesn't, indeed. We'll look into this.

[ert78gb]

@xuhdev If you would like to build the 1.12.12 you have to use the Node.js that described in the .nvmrc file in the project.

[ert78gb]

@xuhdev what is the result of the uname -a on your Debian?

[xuhdev]

My uname -a outputs:

Linux home 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

[mondalaci]

Thanks for your feedback!

According to our testing, Agent works flawlessly on the vast majority of Linux systems. There are some rare exceptions such as yours, and after hours of research, we still don't know in which ways such affected systems differ from the rest.

We don't want to set the setuid bit of chrome-sandbox because it could negatively affect security.

Given that you found a workaround, and that we can't proceed further with this, I'm closing this issue, but we'll keep watching it for new comments along with related issues, and try to solve this if it emerges again.

[xuhdev]

Thanks! I will let you know if I noticed some consistent way to reproduce across distributions.

[ewingd]

I'm running into the same issue on my Debian system.

uname -a output:
Linux desktop 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64 GNU/Linux

[mondalaci]

This does look like a widespread issue on Debian, so reopening it.

[firstnevyn]

So the workaround in the electron bug electron/electron#17972 (comment) of allowing non-privileged users to clone namespaces using sysctl works for me..

sysctl kernel.unprivileged_userns_clone=1

but it's not the default and it requires root.

This sysctl disables a debian/ubuntu? kernel patch that disables unprivilaged user namespaces by default the mainline kernel doesn't support this sysctl.
https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do

[mondalaci]

I'm super glad and thankful you figured this out! Seems like this happens with security-hardened kernels.

Recent Electron releases gave us (any many projects) a lot of headache due to their heavier sandboxing. We couldn't yet figure out how to best solve such issues, but we're on it.

[mondalaci]

@firstnevyn Would you please give a try to the recently pre-released Agent 1.2.15?

Please make sure to not run Agent as root and not use sysctl kernel.unprivileged_userns_clone=1 when testing.

[firstnevyn]

I can confirm this as resolved..
UHK.Agent-1.2.15-linux-x86_64.AppImage.log

[mondalaci]

Awesome, thanks for your feedback!

[xuhdev]

I can confirm this as well. Thanks!

[brycied00d]

Ran into this issue with the 2.0.0 release on ArchLinux (2.0.0-1 https://aur.archlinux.org/packages/uhk-agent-appimage).

Similar issue with other Electron apps (eg: visual-studio-code-bin, Cider) and those can be "easily" worked around with chmod 4755 /path/to/chrome-sandbox, or the system-wide kernel.unprivileged_userns_clone sysctl. However the "only this executable I choose to trust" (chmod 4755) workaround doesn't really work for AppImage-packed applications since chrome-sandbox isn't just laying around, it's unpacked at runtime (it seems - correct me if I'm wrong).

This may be something that can be patched in the Arch Linux's PKGBUILD during build time, but I thought I should raise the issue upstream first, let you know there seems to be a regression.

[mondalaci]

@ert78gb Any ideas about fixing the mentioned issue?

[kh0rvus]

popping in here to attest to the possible regression with this issue on the 2.0.2 release when using ArchLinux with the latest hardened linux kernel.

[ert78gb]

@ra0x1duk3 Cloud you test the https://drive.google.com/file/d/1uEe1g5kOQ3ZkUTfiDiSFkdUYIfiFTwh9/view?usp=sharing version?
If it works I will open a PR

[kh0rvus]

apologies for the delayed response, it's working on my end! thank you!

[ert78gb]

No worries, thank you for the feedback