from https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-12-03/finding/V-230548
RHEL 8 must disable the use of user namespaces.
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. The sysctl --system command will load settings from all system configuration files. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Files are read from directories in the following list from top to bottom. Once a file of a given filename is loaded, any file of the same name in subsequent directories is ignored. /etc/sysctl.d/.conf /run/sysctl.d/.conf /usr/local/lib/sysctl.d/.conf /usr/lib/sysctl.d/.conf /lib/sysctl.d/*.conf /etc/sysctl.conf Based on the information above, if a configuration file that begins with "99-" is created in the "/etc/sysctl.d/" directory, it will take precedence over any other configuration file on the system.
Note: User namespaces are used primarily for Linux containers. If containers are in use, this requirement is not applicable.
However from https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#linux-user-namespaces
From Linux 5.10, all users are allowed to create user namespaces by default. This will allow programs such as web browsers and container managers to create more restricted sandboxes for untrusted or less-trusted code, without the need to run as root or to use a setuid-root helper.
The previous Debian default was to restrict this feature to processes running as root, because it exposed more security issues in the kernel. However, as the implementation of this feature has matured, we are now confident that the risk of enabling it is outweighed by the security benefits it provides.
and https://man7.org/linux/man-pages/man7/user_namespaces.7.html
In RHEL-8.10 my /opt/anaconda3/bin/spyder coredumps when launched with the error of
FATAL:credentials.cc(137)] Check failed: error == EPERM || error == EUSERS || error == EINVAL || error == ENOSYS. :
No space left on device
In my own testing I have discovered setting user.max_user_namespaces = 5 or higher in /etc/sysctl.conf fixed the problem of spyder core dumping when launched, and setting this to 0 was the sole cause of the problem.
Regarding the functionality of what little thus far I have read into about user.max_user_namespaces, is allowing it to have some number (other than setting it to 0) actually better for security?
Is the stigviewer statement regarding primarly for Linux containers accurate?
Can anyone list other software that makes use of user namespaces where setting this to zero would cause a similiar issue?
Is writing software programs in Linux to make use of user namespaces bad or good in the context of security?
