Is it safe to enable user namespaces in CentOS 7.4 and how to do it?

Question

I am trying to use Brave Browser on my CentOS machine, but when I try running it, it gives me the following error.

[19576:19576:0208/180128.818448:FATAL:zygote_host_impl_linux.cc(126)] 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. fish: “./brave” terminated by signal SIGABRT (Abort)

The git page of the project said that I could get an error about sandboxing, and suggested a solution to it.

Here is what it says:

NOTE: If Brave does not start and shows an error about sandboxing, you may need to enable userns in your kernel. Running with the --no-sandbox flag is NOT recommended!

Now, I have three main questions:

1) What exactly does the userns do? I have tried reading the man page on user namespaces, but things got a bit complicated for me, so I would appreciate some explanation.

2) Is it okay if I enable userns, or could it cause some problems?

3) If it is okay, how do I do that? This is the method I found, but I am not sure if that would be the best way to do it.

https://luppeng.wordpress.com/2016/07/08/user-namespaces-with-cent-os-7-rhel/

Solution 1

Namespaces is a kernel feature used by containers like LXC or docker. You have several kinds, PID namespaces, user namespaces,... And you're right, it's quite complicated at first. I find this old blogpost has a good explanation of why it's useful for containers: https://rhelblog.redhat.com/2015/07/07/whats-next-for-containers-user-namespaces/

So, why would I want to do this? Well, this is especially useful for providing root access inside of a container. Imagine that the root user (uid 0) in container A maps to uid 1000, and that root in container B maps to user id 2000 outside the container. Similar to network port mapping, this allows the administrator to give someone uid 0 (root) in the container without giving them uid 0 on the underlying system. It also allows a user to freely add/delete users inside the container.

On RHEL 7.4 it should be included the kernel but disabled by configuration ( number of available namespaces is set to zero by default). Simply execute:

echo 10000 > /proc/sys/user/max_user_namespaces

Solution 2

One can permit user name-space cloning permanently (the default value is 0):

echo user.max_user_namespaces=10000 >> /etc/sysctl.d/98-userns.conf
sysctl -p

This is required for Electron apps (Skype, Teams, Slack, etc), which all use a Chrome sandbox.

Comments

[BlackShift]

There must be more to user namespaces than faking uid 0 in containers, because that can be done with PRoot while having 0 in /proc/sys/user/max_user_namespaces through proot -0.

[eel ghEEz]

@BlackShift, PRoot runs as a regular user and fakes the root ID to satisfy existing programs that check the ID for safety. github.com/proot-me/PRoot/commit/… Docker runs as root but needs mapping that to a host user to satisfy host admins unwilling to deal with files created by root in mounted volumes.

[rinogo]

I'm not sure why, but the echo command gave me the following error (even with using sudo): -bash: /proc/sys/user/max_user_namespaces: Permission denied. Simply editing the file with something like nano worked.

[ronald8192]

@rinogo because sudo echo 10000 > /proc/sys/user/max_user_namespaces run echo as root, when the shell redirect output stream to max_user_namespaces, it is using your current user. In short: echo 10000 | sudo tee /proc/sys/user/max_user_namespaces