Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


according to this reddit post 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


allowPrivilegeEscalation is unrelated to user namespaces. Many vendors do not yet have kernel patches available, but yes that'll eventually be the proper fix.


They 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


Because 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) by default.

As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/



It'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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: