Add instructions on how to run on Debian

[asddsaz]

I installed brave today, and got this errors:

Log:

usr@LINUX:~$ sudo apt install brave
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:

[removed for privacy]

Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
brave
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 97.8 MB of archives.
After this operation, 443 MB of additional disk space will be used.
Get:1 https://s3-us-west-2.amazonaws.com/brave-apt stretch/main amd64 brave amd64 0.25.2-1 [97.8 MB]
Fetched 97.8 MB in 10s (9,152 kB/s)                                                                             
Selecting previously unselected package brave.
(Reading database ... 309999 files and directories currently installed.)
Preparing to unpack .../brave_0.25.2-1_amd64.deb ...
Unpacking brave (0.25.2-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.23-1) ...
Processing triggers for bamfdaemon (0.5.3-2) ...
Rebuilding /usr/share/applications/bamf-2.index...
Processing triggers for gnome-menus (3.13.3-9) ...
Setting up brave (0.25.2-1) ...
usr@LINUX:~$ brave
[16129:16129:1104/213523.113443:FATAL:zygote_host_impl_linux.cc(116)] 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.
Trace/breakpoint trap
usr@LINUX:~$ 

Installation steps followed: https://github.com/brave/browser-laptop/blob/master/docs/linuxInstall.md

[Mikaela]

You can workaround it by enabling user sandboxes with sudo sysctl kernel.unprivileged_userns_clone=1 and to make it permanent echo kernel.unprivileged_userns_clone = 1 | sudo tee /etc/sysctl.d/00-local-userns.conf via me in brave/browser-laptop#15279 (comment).

CC: @bsclifton this is still happening, I just also experienced this on Debian Buster/testing where I didn't have Brave installed before.

[simonorono]

Also happens on Manjaro with Linux 4.19.1 and Brave version 0.56.12 installed with this package

The workaround that @Mikaela commented also works.

[11991:11991:1114/225404.179905:FATAL:zygote_host_impl_linux.cc(116)] 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.
Trace/breakpoint trap (core dumped)

[Brave-Matt]

+1 (2 seperate users) from Community:
https://community.brave.com/t/brave-browser-wont-open-on-debian-64bit/38203/5

[asddsaz]

@Mikaela Appears to have fixed the issue, however I will keep this issue open.

Since most users don't utilize the Terminal very often. An easy to use solution should be reached or these commands need to be added to documentation.

[Mikaela]

Thanks for reminding me about this issue, I had written this note, but I don't think I ever remembered to ask it anywhere.

About user namespaces, after they are enabled, the browser starts and about:sandbox seems OK. But all instructions for namespaces say that users should be assigned more uids in some file which is a step I am skipping.

What are the implications of this? Do Chromium-based browsers on all users claim to be properly userns-sandboxed while being sandboxed into uid of the current user and being able to do everything that the user can do, thus providing weaker security than the setuid sandbox it replaces?

I am feeling too tired for researching this more by myself at the moment and it's not very high priority on my todo list.

---

however I will keep this issue open.

👍 I believe that there is no valid reason for a web browser to demand me changing my kernel configuration, especially if I am running the stock configuration of my distribution, and if I did made my own kernel configuration changes, I expect a lot more apps would be breaking over it.

[cndouglas]

+1 from brave/browser-laptop#15320

[cndouglas]

Related: #1899 (same for Arch Linux)

[Mikaela]

I think this should be renamed into "No usable sandbox" or "Requires userns namespaces" or something similar and that made a duplicate of this one as I understand both are the same issue.

---

I would like to bring this thread aware of what @veox said there (#1899 (comment)):

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.

[Brave-Matt]

+1 from Community:
https://community.brave.com/t/various-bugs-on-arch-or-manjaro-linux/38521/3

[jacobc-eth]

I would like to add on here. There should be no reason to lower the security settings of the kernel as a workaround. Here is what the Arch documentation writes about this:

Unprivileged usage is disabled by default unless the kernel.unprivileged_userns_clone sysctl 1 is set to 1 , since it greatly increases the attack surface for local privilege escalation.

https://wiki.archlinux.org/index.php/security

This seems like a significant security issue and it is very bad that many people are being told to reduce their kernel security. We need to solve the internal sandbox issue within Brave.