broken sandbox (archlinux)

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

[jacobc-eth]

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

1. 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.
2. 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.

[fmarier]

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