feature request: alternative to user namespace sandbox on Linux

(follow up to #1986 since that issue got closed by my PR to change the Linux sandboxing error message)

Problem:

1. On Linux, Brave generally does not run unless either the --no-sandbox flag is passed or user namespaces are enabled.
2. Previously, the default error message told users to try running with --no-sandbox. In https://github.com/brave/brave-core/pull/1204, I changed it to tell users they probably need user namespaces enabled. The rationale was that running with any sandbox, even a subpar one, is better than running without any sandbox.
3. Users often complain to us that we should not be encouraging enabling of userns because it’s an insecure/poorly-designed feature. Citations include https://lists.archlinux.org/pipermail/arch-general/2017-February/043066.html and https://wiki.archlinux.org/index.php/security#Sandboxing_applications.

The main argument from https://lists.archlinux.org/pipermail/arch-general/2017-February/043066.html is that userns has so many vulnerabilities to the point of being useless, and hence is security theater; in other words we should assume any code that runs with some privileges in a user namespace can run with those privileges on the host itself.

However, if that were true, running Brave in a userns sandbox would be equivalent to running Brave without a sandbox. Does userns actively make security worse? (Other than perhaps luring people into a false sense of security.)

Some potential options:

1. In the error message (https://github.com/brave/brave-core/pull/1204), mention that userns is considered harmful by some and the other option is to just run without the sandbox. I’m not a big fan of this since it’s a complicated and not-necessarily-actionable message for non-technical users.
2. Ship the Chromium setuid sandbox which is supposedly being deprecated soon or was already deprecated, also citing security reasons: https://bugs.chromium.org/p/chromium/issues/detail?id=312380
3. Write our own sandbox 😦

[madaidan]

Can you point out the communities which don’t support user namespaces?

Debian, one of the most popular linux distros disables unprivileged user namespaces by default.

The Arch Linux linux-hardened kernel disables unprivileged user namespaces.

The KSPP recommends to disable them along with tons of other security experts so you can bet many security focused Linux users will be following their advice.

And many more.

Namely the concern I had was around dynamic library loading in a setuid environment before any of the rendering threads launch.

AT_SECURE is set on setuid/setgid binaries on Linux which prevents that from being exploited entirely.

There has not been a single known privilege escalation exploit in chromium’s suid sandbox.

[jacobc-eth]

This issue has caused a lot of damage to the reputation of Brave in the F/OSS community (look at the issues linking to this one listed up above or the dozens of other threads across various different Linux communities that have removed Brave from their repositories). That alone should be sufficient incentive to take this issue seriously. This issue has now been open for 9 months, without any security fix even being worked on. Please, please take this issue seriously.