-1

A security rule of RHEL 8 must disable the use of user namespaces. states

Discussion: 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.

Fix Text: user.max_user_namespaces = 0 in a sysctl.conf followed by sysctl --system

  • Does using user namespaces, for what I think is an unlimited (65535) value from a clean default install from rhel-8.10.iso, cause an increased risk as an additional attack vector ?
  • Is User Namespaces an unnecessary capability ?
  • Can the rationale behind user namespaces be stated here in layman's terms? Why is it a [good?] thing ?
Improve this question
1

3 Answers 3

Reset to default
4

I think this is obvious tradeoff, you will get flexibility and non-root isolation but in other hand you will increase attack surface.

So, we are in fact mixing different targets - user or application and security, their goal and perspective is different.

Considering layman's terms it is good because users or apps gets place to safely run scripts and containers in isolated env that is non root, you are not giving sudo or chance to destroy host while there is place for experiments (ans we know that experiments move world forward).

And what about security ? Security itself is not about above paragraph, security is about risk or not. So disable when you are not using or make tradeoff when you will find it useful.

Improve this answer
2
  • my experience is the security discussion goes subjective and theatrical especially for those using the reduced attack/risk surface argument when they are not the ones using the system made dysfunctional by such guidelines. If it's just about risk then we need to stop using computers, and go back to 6 foot separation and complete isolation work from home. Commented Apr 24 at 14:58
  • and put the directional arrows on the supermarket floors and follow them when shopping Commented Apr 24 at 14:59
3

See Muru's answer 18 months ago in AskUbuntu. (copied into this answer from a comment) What I read there explains the rule and the mixed answers you're getting for this question:

  • In the past, Debian and Ubuntu defaulted to disabling the creation of user namespaces. When the feature was very new, there was a perception that it could/would expose security issues in the kernel. (details of the "issues" were not present in the AskUbuntu answer)
  • In Debian Bullseye and Ubuntu sometime after the 23.10 release, the default was changed. Debian said the implementation had matured, reducing the risks of enabling user namespaces.

I assume the RH8 "rules" you mention in your question are from a security review, perhaps from pre-packaged hardening or audit software, or from a more manual security checklist. My point below is useful to remember in the context of security audits:

  • "Rules" or "Guidelines" used for system hardening/auditing will often lag behind the current technology.

An audit rule may not be aware of a new feature or new software, and fail to recommend that the feature/software be locked down. Technology moves fast, and audit rules/guidelines often don't change quickly. And this works for the opposite case, too. A feature or software can become more secure but an audit rule still says to disable/remove it. The rule simply lags behind the technology. This is very likely why the rule recommends disabling user namespaces while folks like Marcus M. say the rule is nonsensical.

Improve this answer
3
  • I'd agree, but user namespaces have been around for quite a while (decades), and they are not at all "experimental stuff"; without them, you can forget about much more security-sensitive things: Containers plain wouldn't work. Forget about Docker, Podman, lxc, kubernetes… When RHEL8 came out, this was already clear. Commented Apr 18 at 19:14
  • @MarcusMüller are you talking about the same permission as Muru's AskUbuntu answer is talking about? The quote from Debian in Muru's answer says "From Linux 5.10, all users are allowed to create user namespaces [not just root]". It seems to me the issue in that question and this question centers around who can create user namespaces, not the user namespaces themselves. My summary of Muru's answer didn't outline this point very clearly. I assumed people would read the answer directly if they cared about it. Commented Apr 19 at 6:44
  • thanks... public.cyber.mil/stigs/compilations you can see the latest v2r4, my v2r2 asks for usernamespace disable but they did not ask back in v2r1 or v1r#.... they still guideline the disabling of runlevel 5 saying graphics has a long history of vulnerability so... Commented Apr 24 at 14:52
2

That seems to be a nonsensical rule.

User namespaces are not additional attack surface (they don't give the executing user any new privileges), and they have definite usage benefits. In fact, many security-enhancing technologies (running user session daemons without access to all user files, or even things like bwrap / flatpak) depend on them!

I've never read a rule like the one you're seeing, but quite frankly, this sounds like it comes from a classical "checkbox-ticker pseudo-security audit". If they don't know about the security-enhancing usages of Linux namespaces, maybe don't listen to them too much.

Can the rationale behind user namespaces be stated here in layman's terms? Why is it a [good?] thing ?

You can see all the other user IDs and Group IDs in your system. You can see the "as real as it gets" / directory of your system.

For you it's always the same user ID that runs some daemons. If in your world, a file needs to be changed by the root user, then the daemon that has to do that needs to run as root.

What if your system could spawn a process which only sees "their" little view of all this? As in "act as if there's a little magical door, behind which things look like there were files that can only be manipulated by root, and there's processes that look like they run as root, but actually, root is just a fancy name and has same privileges as the user opening that little door?

That's what a user namespace does. It allows you to say "this new process (and all children processes) get a view of the world in which they think they are more powefull than they really are". The process internally run under different User IDs than what it looks from the outside, and all these user IDs have the same, or less privileges than the user that started that namespace "mother" process.

That's a pure reduction of attack surface.

Improve this answer
7
  • see public.cyber.mil/stigs/compilations and download the public U_SRG-STIG_Library_April_2025.zip and look at the U_RHEL_9_V2R4_STIG.zip within using their STIGViewer under public.cyber.mil/stigs/srg-stig-tools Commented Apr 24 at 15:00
  • use the older 2.18 viewer Commented Apr 24 at 15:01
  • I'm not sure whether wading through government regulation is helpful here. You asked for a reasoned answer whether something is technically sensible, not whether it's recommended by an official party. Commented Apr 24 at 15:05
  • 1
    not saying to wade through regulation... you said you never seen a rule like this... now you (or anyone) can. Some are good and logical and helpful. Others... well.... look for yourself if interested. The user namespace thing the way they worded it seems like a better way to make life hard and cause things not to work rather than decrease risk. Commented Apr 24 at 15:17
  • ah sorry, @ron, I'm thankful that you supplied that link! I'm just really not convinced whether, unless you are doing an audit, you should be working through them :) Sorry I phrased it such that it sounds it's not good that you shared the source. Thank you! Commented Apr 24 at 17:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.