Enabling unprivileged user namespaces can make severe vulnerabilities in the Linux kernel much more easily exploitable. If you did not intend to enable it, you should ensure it is disabled. Numerous vulnerabilities that are found regularly are often only exploitable by unprivileged users if unprivileged user namespaces are supported and enabled by the kernel. Unless you truly need it, just disable it.
The reason for this is that much of the kernel that is only intended to be reachable by UID 0 is not audited particularly well, given that the code is typically considered to be trusted. That is, a bug that requires a UID of 0 is rarely considered a serious bug. Unfortunately, unprivileged user namespaces make it possible for unprivileged users to access this very same code and exploit security bugs.
From Brad Spengler in 10 Years of Linux Security, describing exploitation trends:
Attack surface exposed by unprivileged user namespaces isn’t decreasing anytime soon
- Even more functionality being exposed:
- 2abe05234f2e l2tp: Allow management of tunnels and session in user namespace
- 4a92602aa1cd openvswitch: allow management from inside user namespaces
- 5617c6cd6f844 nl80211: Allow privileged operations from user namespaces
- "Does this newly-allowed code pass existing fuzzing tests?" doesn’t appear to be a consideration for enabling such functionality
A few examples of vulnerabilities only exploitable on systems with unprivileged user namespaces:
Note that this particular sysctl may get deprecated and possibly removed soon. This is because a little more attention is being spent on finding unprivileged user namespace bugs and the feature is not quite as horribly insecure as it once was. Unfortunately, it is still quite insecure (in part due to the lack of CVE reporting for security bugs in the Linux kernel). If that is the case for your particular distro, you can disable user namespaces directly by setting user.max_user_namespaces = 0
.