3 ms·
Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile)
by parliament32 6mo ago
Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.
- j16sdiz 6mo agoaccording to this reddit post https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment/oj4cs67/ https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment...? > the primary mitigation is still patching the node kernel; user namespaces are blast-radius reduction, not a complete mitigation for this path
- parliament32 6mo agoallowPrivilegeEscalation is unrelated to user namespaces. Many vendors do not yet have kernel patches available, but yes that'll eventually be the proper fix.
- TZubiri 6mo agoThey have a setting for that? That's crazy, feels like prompting "make no mistakes" to the llm. If it works, when would you want it turned on? Why isn't false the default
- parliament32 6mo agoBecause it would break all setuid binaries? Same reason the Linux kernel doesn't set no_new_privs (https://docs.kernel.org/userspace-api/no_new_privs.html https://docs.kernel.org/userspace-api/no_new_privs.html) by default. As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/ https://kubernetes.io/docs/concepts/security/
- TZubiri 6mo agohttps://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted https://kubernetes.io/docs/concepts/security/pod-security-st... Relevant section
- stratos123 6mo agoIt's equivalent to setting no_new_privs on the container process, so it'd mean you have to grant a privelege to the container process if you want any children to have access to it. It sure sounds funny in a CVE context, though.