Brave-browser: broken sandbox (archlinux)

Created on 30 Oct 2018 · 5Comments · Source: brave/brave-browser

Binary: https://github.com/brave/brave-browser/releases/download/v0.55.21/brave-browser_0.55.21_amd64.deb

OS:; archlinux

kernel: 4.19.0

Log
trap' para punto de parada/seguimiento (core' generado)

dmesg log
[28488.802310] traps: brave[21676] trap int3 ip:55812609b770 sp:7ffeb929bd90 error:0 in brave[558123e06000+65e2000]
[28488.802396] audit: type=1701 audit(1540863866.209:131): auid=1000 uid=1000 gid=1000 ses=2 pid=21676 comm="brave" exe="/opt/brave.com/brave/brave" sig=5 res=1

also
it works with --no-sandbox flag

OLinuarch closeduplicate prioritP4

Source

HotelBellaMuerte

Most helpful comment

@Liunkae I believe this issue should be reopened, and had mentioned it with @bbondy in the related PR. Two reasons:

Reducing the security of the user's OS is not an acceptable security solution. Earlier in this thread, @veox linked to the statement from Arch as to why user name spaces are not enabled by default. Arch has stated that enabling this parameter greatly increases the attack surface. This is not an acceptable solution. We need a real sandbox solution.
Even beyond the major security concerns, the Debian instructions linked do not resolve the issue for Arch Linux users. Many distros beyond Arch each have user name space disabled for security reasons, and the commands for changing kernel security parameters will vary across them. Having users learn the correct command for their distro is unscalable and an ugly solution. This Github issue was created for Arch Linux, so it makes no sense to close it with a reference to a Debian solution.

Please, please consider a better sandboxing solution. This is an opportunity for Brave to lead and do better than Chromium.

jacobcantele on 13 Feb 2019

👍28

All 5 comments

cc @mbacchi

bbondy on 30 Oct 2018

A commonly-quoted workaround is enabling unprivileged user namespaces using

sudo sysctl kernel.unprivileged_userns_clone=1

However, before doing that, see this reply on arch-general for why it's not enabled by default.

Note also that (from the link above):

Moreover there are many applications that use this feature to provide or enhance security
Among them are:

lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox, chromium

There's one well-written sandbox there (Chromium's usage) and it doesn't require this feature.

Which is true: Chromium works just fine on Arch with the defaults, so I don't see a reason why Brave shouldn't.

veox on 19 Nov 2018

Related: #1986 (same for Debian)

cndouglas on 5 Dec 2018

@Liunkae I believe this issue should be reopened, and had mentioned it with @bbondy in the related PR. Two reasons:

Reducing the security of the user's OS is not an acceptable security solution. Earlier in this thread, @veox linked to the statement from Arch as to why user name spaces are not enabled by default. Arch has stated that enabling this parameter greatly increases the attack surface. This is not an acceptable solution. We need a real sandbox solution.
Even beyond the major security concerns, the Debian instructions linked do not resolve the issue for Arch Linux users. Many distros beyond Arch each have user name space disabled for security reasons, and the commands for changing kernel security parameters will vary across them. Having users learn the correct command for their distro is unscalable and an ugly solution. This Github issue was created for Arch Linux, so it makes no sense to close it with a reference to a Debian solution.

Please, please consider a better sandboxing solution. This is an opportunity for Brave to lead and do better than Chromium.

jacobcantele on 13 Feb 2019

👍28

This was also reported in #6247 and fixed in https://github.com/brave/brave-core/pull/4223.