Brave won't start [sandbox]

[ghost]

• Did you search for similar issues before submitting this one?
  Yes

• Describe the issue you encountered:
  Brave won't start

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Debian 9 (Testing) Kernel 4.9

• Brave Version (revision SHA):
  Brave 0.13.0 808997e

• Steps to reproduce:

1. Just try to open Brave

• Actual result:
  Brave won't start

• Will the steps above reproduce in a fresh profile? If not what other info can be added?
  Yes

• Is this an issue in the currently released version?
  Yes

• Can this issue be consistently reproduced?
  Yes

• Screenshot if needed:
  

[Fromax]

I'm on Debian 8 (Jessie) with default 3.16.0-4 kernel and get similar issues.
Downgrading Brave to 0.12.15-1 "fixes" it 😉

[6871:6871:0131/161507:FATAL:zygote_host_impl_linux.cc(107)] No usable sandbox! 
Update your kernel or see 
https://chromium.googlesource.com/chromium/src/+/maste/docs/linux_suid_sandbox_development.md
for more information on developing with the SUID sandbox. 
If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

Using brave --no-sandbox in a terminal still fails:

An uncaught exception occurred in the main process Uncaught Exception:
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /tmp/.org.chromium.Chromium.c4FndO)
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:168:20)
    at Object.Module._extensions..node (module.js:600:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:182:18)
    at Module.load (module.js:490:32)
    at tryModuleLoad (module.js:449:12)
    at Function.Module._load (module.js:441:3)
    at Module.require (module.js:500:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/share/brave/resources/app.asar/node_modules/keytar/lib/keytar.js:4:12)
    at Object.<anonymous> (/usr/share/brave/resources/app.asar/node_modules/keytar/lib/keytar.js:58:4)
Waiting 60 seconds for process to load
Process failed to load within 60 seconds

[bbondy]

Duping to #6909

[bbondy]

The fix will be included in 0.13.1

[Doomineer]

The problem remains in Debian Linux 8.6 (jessie) even with this fix (0.13.1)

[Fromax]

0.13.1 is now working with brave --no-sandbox (Jessie with 4.8.0 kernel)...

[lekhnath]

brave@0.13.2 is working for me on Ubuntu 13.10 with brave --no-sandbox

[BostonEnginerd]

I'm also seeing the same issue on 0.13.1 - Debian 8, with the 4.9 kernel from backports.

Same with 0.13.4.

[makayabou]

I'm also seeing the same issue on 0.13.2-1 on Debian 8 with 4.9 kernel from backports.
But I can start brave using --no-sandbox

[huuhaa]

0.13.4-1 Seems to work with kernel 3.16.0-4 when using --no-sandbox. Hopefully sandbox works with stretch. OT: Gonna upgrade when bunsenlabs is ready for that (haven't yet read much about that, but someone have had problems so still waiting...).

Edit: Upgraded to Stretch (kernel 4.9.0-1-amd64), still doesn't work without --no-sandbox. (Also seems that there's not yet stretch repos for brave. but that's offtopic)

[solarchemist]

I just observed the same issue. Brave 0.13.4-1 and kernel 3.16.0-4 on Debian Jessie.
But it did start with --no-sandbox. But still kind of off-putting for the merely curious user...

[posix4e]

@Chapec can you test to see if docker works on your system. We use the same APIs

[alfredocdmiranda]

@posix4e I am using the same version and kernel version than @chepec. And docker works on my pc.

[posix4e]

Oh dear, this is something else than i thought

[posix4e]

@alfredocdmiranda I see that the problem happens even if you disable the sandbox, so this is actually a different bug than this ticket addresses. I'll file a new issue

[posix4e]

@alfredocdmiranda @chepec #7328

[huuhaa]

@posix4e How about this original problem #6902 about sandbox? This issue seems to be closed but problem still exist, so I'm bit confused that is problem solved in your opinion or not?

[jordan31bit]

Still facing the same problem with kernel 4.9 brave 0.13.4 on debian stretch. though i can at least use the browser with with --no-sandbox.

[Fromax]

Brave 0.13.5 (rev 1db81cb) on Jessie with 4.9 kernel. Still requires --no-sandbox to work...

[6266:6266:0304/145920.639795:FATAL:zygote_host_impl_linux.cc(107)] No usable sandbox! 
Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox.
If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
Aborted

This issue needs to be re-opened.

[apinsard]

I packaged brave for Funtoo Linux. I do not face this issue myself, but some users do, with 0.13.1. I just added 0.13.5 and 0.12.15, so they can test with these versions. I'll report back.

Edit: I confirm users still have the same issue with 0.13.5. Version 0.12.15 works fine for them. I personally can launch either version successfully without --no-sandbox. We did not manage to figure out why it works on my machine and not on theirs. We compared some kernel settings related to sandboxing, but they did not differ:

CONFIG_USER_NS=y             
CONFIG_PID_NS=y                                         
CONFIG_NET_NS=y
CONFIG_SECCOMP_FILTER=y

[huuhaa]

@Fromax Sadly it seems like it's more important to keep the number of open issues low than actually fix the issues. I know / hope this is not the case, but still feels like it sometimes. I'm currently using Brave only with Android, was forced to make this switch back to firefox (not gonna use with --no-sandbox)...

[MidnightJava]

Enabling user namespaces in the kernel does not work on CentOS 7 (per my Nov 29 post above). Every reference to Linux I've seen regarding this issue actually refers only to debian. I have not found any workaround that enables me to run Brave on RHEL.

[posix4e]

@MidnightJava Does you CentOS 7 setup support docker and firejail?

[MidnightJava]

@posix4e: I don't use firejail, but I use docker quite a bit, with no issues.

[posix4e]

@MidnightJava I am trying to figure out what's not working . We rely on the same kernel api as docker
Do you get

8531:8531:1224/072104.919291:FATAL:zygote_host_impl_linux.cc(123)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

[MidnightJava]

Yes, I get the same thing. Here's my output.

$ brave
[12093:12093:0112/172017.622146:FATAL:zygote_host_impl_linux.cc(123)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
Aborted (core dumped)

[posix4e]

@MidnightJava can you post a recursive strace , strace -fi -o foo brave

then cat foo | nc termbin.com 9999 and tell me the url

[MidnightJava]

@posix4e: Thanks for working on this. The URL is http://termbin.com/4213

[jbrockc]

I did the following for it to survive reboot (system Debian 9).
echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns.conf
Source: https://superuser.com/questions/1094597/enable-user-namespaces-in-debian-kernel#answer-1122977

[hugobuddel]

Have to run Brave (0.19.134) with --no-sandbox on Scientific Linux 7.4 as well (kernel 3.10.0-693.11.6.el7.x86_64). Could someone explain why this is dangerous?

The link that is included with the error says that "The Linux SUID sandbox is almost but not completely removed.", so the sandbox is outdated anyway?: https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md

I don't have root access on this machine, so this seems to be the only way to run Brave. All other browsers run fine, so is this a Brave specific thing?

[ghost]

Hi,

I'm facing the same issue.

Linux

Distributor ID:	Debian
Description:	Debian GNU/Linux 9.3 (stretch)
Release:	9.3
Codename:	stretch
4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

Brave :
[12384:12384:0127/195758.825780:FATAL:zygote_host_impl_linux.cc(126)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

[posix4e]

@thejuln seems as though others listed a fix. Did you try it?

[keverets]

@posix4e that's not a fix, it's a bad workaround. Brave is still not an acceptable browser for people when the first experience is a core dump with improper instruction.

[ghost]

Hi @posix4e

I followed the link provided by "jbrockc" and it's works, I agree with @keverets that it's more a Workaround than a Fix.
I'm able to launch Brave through command line or desktop icon but I have the following message :

ATTENTION: default value of option force_s3tc_enable overridden by environment.
Crash reporting enabled
[30201:30201:0128/001110.401280:ERROR:CONSOLE(52761)] "(node) warning: possible EventEmitter memory leak detected. %d listeners added. Use emitter.setMaxListeners() to increase limit.", source: chrome://brave/usr/lib/brave/resources/app.asar/app/extensions/brave/gen/app.entry.js (52761)
[30201:30201:0128/001110.401339:ERROR:CONSOLE(52761)] "(node) warning: possible EventEmitter memory leak detected. %d listeners added. Use emitter.setMaxListeners() to increase limit.", source: chrome://brave/usr/lib/brave/resources/app.asar/app/extensions/brave/gen/app.entry.js (52761)

[melroy89]

In Debian enable the userns kernel option, temporally would be:
echo 1 > /proc/sys/kernel/unprivileged_userns_clone

Permanent solution would be:

echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns.conf
service procps restart

[MidnightJava]

Is there any progress in Brave supporting RHEL? every time I see an update, I give it a try, and always I get the unresolvable "No usable sandbox!" error.

[ThomasHermann]

Brave will run on RHEL, at least I've run it on Scientific Linux 7.4 which should be equivalent. The default number of max_user_namespaces is 0, so by providing a value greater than 0, you can run Brave browser. Not sure that you need 10,000, but I've not bothered to experiment with other values.

echo 10000 > /proc/sys/user/max_user_namespaces

The following post explains the details.

https://superuser.com/questions/1294215/is-it-safe-to-enable-user-namespaces-in-centos-7-4-and-how-to-do-it

[MidnightJava]

Thanks, it was the setting a value for max_user_namespaces > 0 that did the trick. I enabled user namespaces months ago when I first tried to use Brave, and I never saw any mention of the need to set that value in any of the instructions I consulted for enabling user namespaces—just the need to set the boot args. Maybe that value is not defaulted to zero on debian, I don't know. You're the first person that was able to tell me how to make it work in RHEL.

[hugobuddel]

Why does Brave use user namespaces?

The link says that "this is especially useful for providing root access inside of a container". Why would Brave need root in a container, or is there another use case? The error message is very non-instructive.

Also, why exactly is it dangerous to run Brave with --no-sandbox? None of my other browsers have a problem on Scientific Linux 7.4; are all of them unsafe too, or is it only Brave that is unsafe without user namespaces? If only Brave is dangerous to use w/o namespaces, can we fix Brave?

By the way, I can 'fake uid 0' with PRoot, so could someone elaborate on the exact problem that namespaces solve beyond what PRoot can do?

See https://github.com/proot-me/PRoot

$ cat /proc/sys/user/max_user_namespaces
0
$ id
uid=30(XX) gid=30(XX) 
$ ./proot-x86_64 -0
# whoami
root
# id
uid=0(root) gid=0(root)

Any more information would be appreciated because I can't fix the problem (no real root) and the warning message seems very severe.

Should I stop using Brave because it is too dangerous to do so?

[diracdeltas]

See https://bugs.chromium.org/p/chromium/issues/detail?id=312380 for more info on why we don't support the setuid sandbox, which is what chrome uses for sandboxing on systems that don't support user namespaces.

[diracdeltas]

See https://chromium.googlesource.com/chromium/src/+/b4730a0c2773d8f6728946013eb812c6d3975bec/docs/design/sandbox.md for what sandboxing is in chrome/brave and why it's important

[audricd]

having the issue. I see its mentioned that if docker works on a machine, this wont either because they use the same API. In other words, this wont work on any vm of any kind unless you have nested virtualization. Which is a shame. VDIs are growing and growing

[lpryszcz]

problem remains in v. 0.23.73

[ghost]

the same problem remains in v. 0.23.79-1 (so it works with --no-sandbox flag)
I'm on a clean Debian 9 stable, 4.9.110-3+deb9u2 (2018-08-13) x86_64 GNU/Linux

[tildelowengrimm]

This issue should be resolved with the Chromium-based refactor. We don't plan to do any more work on this issue in the current Muon-based Brave. If this issue still exists with the re-factor, please open a new issue in https://github.com/brave/brave-browser/issues .