Can't open, SUID sandbox helper binary problem

[j3st3r-LulzSec]

I did browse issues and couldn't find a similar issue the only way it'll let me run this is as root not regular user and only after restarting my whole system I must be doing something wrong when I duo click it wont open and when I try from terminal it says its running in the background although I killed all processes

[GitSquared]

Distro? Machine specs? eDEX version?

[j3st3r-LulzSec]

im running Parrot mate 4.7 debian / laptop / eDEX-UI.Linux.x86_64
id much rather build it locally versus running appimage but the instructions arent very clear to do so and i dunno what dependencies are involved

[niklas2810]

Can you provide any logs? To me it sounds like a problem with the setup of your machine, but maybe the logs reveal some details.

In order to build eDEX-UI on Linux, use the steps described in the README:

1. npm run install-linux
2. npm start

Maybe this could give you additional insight.

[j3st3r-LulzSec]

i rebuilt it however i dont want to run this root rebuild went good but heres the msg i get when i run (npm start)

✔ Rebuild Complete
╭─░▒▓    ~/De/edex-ui  on   master ▓▒░
╰─ npm start ─╯

[email protected] start /home/j3st3r/Desktop/edex-ui
electron src --nointro

[3635:1003/160750.571922: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/j3st3r/Desktop/edex-ui/node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.

[j3st3r-LulzSec]

─ npm start ─╯

[email protected] start /home/j3st3r/edex-ui
electron src --nointro

sh: 1: electron: not found
npm ERR! code ELIFECYCLE
npm ERR! syscall spawn
npm ERR! file sh
npm ERR! errno ENOENT
npm ERR! [email protected] start: electron src --nointro
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?

npm ERR! A complete log of this run can be found in:
npm ERR! /home/j3st3r/.npm/_logs/2019-10-03T20_20_55_542Z-debug.log

[GitSquared]

@j3st3r-LulzSec

[3635:1003/160750.571922:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly.

The latest builds of Chromium embedded into Electron have sandboxing enabled by default. On Linux this requires permission to run unprivileged containers in "User Namespaces". Most distros now default to allowing the use of this kernel features for all users, but the default used to be to only allow root to access it.

To enable user namespaces for non-root users (from ArchWiki):
sysctl kernel.unprivileged_userns_clone=1

You should then be able to start eDEX (cloned & build or through an AppImage release.)

[j3st3r-LulzSec]

I don't want to go that route and alter my kernel by lowering security it can cause user escalation and cause apps to break out

[GitSquared]

This setting is default on most Linux distros now. If you don't trust it, I'm afraid you have no other option than to run eDEX as root.

I strongly recommend that you do not use any of the pre-sandbox eDEX releases as you'd expose yourself to way more serious security issues.

[j3st3r-LulzSec]

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:

{1} 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.

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

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.

electron/electron#17972 (comment)

Maybe add a bootstrap script into the appimage, and remove the chrome-sandbox binary from distribution,its Unfortunate that electron-builder doesn't support any of this, so maybe you could add a hook and do it yourself....

[GitSquared]

so maybe you could add a hook and do it yourself....

I'm watching a PR working on that idea in electron-builder: electron-userland/electron-builder#3872

I believe the security risks of enabling user namespaces are very limited now that they have matured a bit, but I do understand that this is still subject to debate. I will look into providing sandbox alternatives in eDEX, but I'd prefer this to be handled upstream.

[GitSquared]

@j3st3r-LulzSec It's been a while, but a quick update on this: the upstream PR I mentioned has been merged and the next release of eDEX should fix any sandbox issues on Linux.

[j3st3r-LulzSec]

Thanks for the update Sent from ProtonMail mobile

…

-------- Original Message --------

On Oct 31, 2019, 6:36 AM, Gaby wrote: ***@***.***(https://github.com/j3st3r-LulzSec) It's been a while, but a quick update on this: the upstream PR I mentioned has been merged and the next release of eDEX should fix any sandbox issues on Linux. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#588?email_source=notifications&email_token=ANHQEF3IDJLZTFJZNDZOEDLQRKYLXA5CNFSM4I5F6KQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECXIJHA#issuecomment-548308124), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ANHQEF5LPISREAH7FFL5LX3QRKYLXANCNFSM4I5F6KQQ).