Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

broken sandbox (archlinux) #1899

Closed
HotelBellaMuerte opened this issue Oct 30, 2018 · 5 comments
Closed

broken sandbox (archlinux) #1899

HotelBellaMuerte opened this issue Oct 30, 2018 · 5 comments
Labels
closed/duplicate Issue has already been reported OS/Linux/arch priority/P4 Planned work. We expect to get to it "soon".

Comments

@HotelBellaMuerte
Copy link

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

@bbondy bbondy added this to the 1.x Backlog milestone Oct 30, 2018
@bbondy
Copy link
Member

bbondy commented Oct 30, 2018

cc @mbacchi

@mbacchi mbacchi added the priority/P4 Planned work. We expect to get to it "soon". label Oct 31, 2018
@veox
Copy link

veox commented Nov 19, 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.

@cndouglas
Copy link
Contributor

Related: #1986 (same for Debian)

@jacobc-eth
Copy link

@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
Copy link
Member

fmarier commented Dec 18, 2019

This was also reported in #6247 and fixed in brave/brave-core#4223.

@fmarier fmarier closed this as completed Dec 18, 2019
@fmarier fmarier added the closed/duplicate Issue has already been reported label Dec 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed/duplicate Issue has already been reported OS/Linux/arch priority/P4 Planned work. We expect to get to it "soon".
Projects
None yet
Development

No branches or pull requests

8 participants