Browser-laptop: 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:

• 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 :wink:

[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 https://github.com/brave/browser-laptop/issues/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]

[email protected] 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 https://github.com/brave/browser-laptop/issues/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?

[Trumpy]

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

[jonathansampson]

@huuhaa I can assure you that we take these issues very serious. I'll reach out to the team and request that we give this issue another evaluation. Thank you for your patience and support.

[diracdeltas]

i think 0.12.x didn't have sandboxing enabled on Linux, so it makes sense that it would work without the --no-sandbox flag.

https://github.com/jessfraz/dockerfiles/issues/149 might help?

[ancho]

Found this little thread. And it works for me with debian 8.7, kernel 4.9.0-0.bpo.1-amd64 and brave 0.13.5.

[srirambv]

The latest version works on Debian with --no-sandbox parameter.

[ancho]

huh? I use the linux-image from jessie-backports. And it didn't work for me. Anyways, call it a documentary addition :)

[diracdeltas]

You should not run Brave with --no-sandbox since sandboxing is important for security. It works for me on Debian 8 and Fedora as-is.

[ancho]

i don't :)

[diracdeltas]

@ancho right, i was replying to @srirambv. thanks for the link to https://superuser.com/questions/1094597/enable-user-namespaces-in-debian-kernel#1122977, i'll add it to linux docs.

[diracdeltas]

https://github.com/brave/browser-laptop/blob/master/docs/linuxInstall.md has been updated

[huuhaa]

Thanks! Enabling user namespaces did the trick for Debian Stretch! Now using brave again. :)

[bbondy]

Does this mean we won't work out of the box on stretch @diracdeltas ?
Should we setup a repo for stretch by the way?

[apinsard]

I confirm setting unprivileged_userns_clone to 1 fixed the issue for Funtoo users that experienced it. It looks like they had /sys/kernel/unprivileged_userns_clone set to 0, while users not experiencing the issue had no such file. I added some post-install information to let users know that they must edit sysctl.conf if they experience the issue.

Would be nice if the error message told to edit sysctl.conf instead of suggesting to try with --no-sandbox flag.

[Fromax]

Now works on Jessie with kernel.unprivileged_userns_clone=1.

Would be nice if the error message told to edit sysctl.conf instead of suggesting to try with --no-sandbox flag. (@apinsard)

I second this!

[ghost]

I have this problem too, I don't mind using brave without sandbox anyway... Is it possible to run the browser without sandbox by default, without the "--no-sandbox" parameter? I'm using ubuntu 16.04 via crouton on an Asus c300 chromebook (the 2GB version)

[luixxiul]

@Jimster121 did you try the solution here: https://github.com/brave/browser-laptop/issues/6902#issuecomment-285130546?

[ghost]

I tried it but I failed. Keep in mind that these instructions are for Debian and not Ubuntu (although it's Debian-based). If it actually works for Ubuntu then I believe that the problem is with my Ubuntu installation (crouton on a chromebook). Can somebody tell me how to set brave browser without sandbox by default ?

[luixxiul]

According to https://community.brave.com/t/is-sandbox-active-on-linux/4343/3?u=suguru, firejail would enable to run Brave by sandboxing.

Alternatively, you can install firejail and run Brave within firejail.

https://github.com/netblue30/firejail

I am not sure if firejail works properly. CC @diracdeltas for a comment.

[jamieson99]

Here's the quick fix (h/t to ancho above) if you're running into this on Debian (and presumably also Funtoo with the Debian kernel):

echo kernel.unprivileged_userns_clone=1 | sudo tee - /etc/sysctl.d/99-fixbrave.sh
sudo sysctl kernel.unprivileged_userns_clone=1

[MidnightJava]

I have this problem on Centos 7, and enabling user namespaces in the kernel didn't resolve it. I followed these instructions for updating the kernel args, and here are the args I have after reboot.

# grubby --info="$(grubby --default-kernel)"
index=0
kernel=/boot/vmlinuz-3.10.0-693.5.2.el7.x86_64
args="ro crashkernel=auto rhgb quiet rd.shell=0 LANG=en_US.UTF-8 user_namespace.enable=1"
...

Anyone have any further ideas on using Brave on CentOS, other than running with --no-sandbox?

[keverets]

Why is this issue closed? Is there a more appropriate issue to be reporting this problem?

The startup of brave 0.19.116-1 without extra workarounds still says:

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.

Adding an instruction to documentation that's stored and used elsewhere is not sufficient, as the program as installed gives misleading errors and dumps core. That's still a terrible start-up experience for users.

[grokk]

The --no-sandbox issue with Brave continues into January 2018 with my own Debian 'testing' setup, kernel 4.14.7-1 ... and the sysctl setting of /proc/sys/kernel/unprivileged_userns_clone for userspace namespaces is the solution for it. Perhaps this is not an issue with a fresh install, eh..?

Kudos to @ancho for finding for us what must be THE elegant stopgap solution to the actual issue, in any case.

[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?

[TheJuln]

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.

[TheJuln]

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)

[danger89]

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

[tomlowenthal]

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 .