Update unprivileged_userns_restriction

John Johansen 2023-08-31 15:00:35 +00:00
parent f6ebc5f3b0
commit 513b06423e
No known key found for this signature in database

@ -13,6 +13,8 @@ This has lead to many real world CVEs. Examples (to pick a few):
* [CVE-2022-25636](https://nvd.nist.gov/vuln/detail/CVE-2022-25636): to exploit, need to be able to add netfilter rules, granted by `CAP_NET_ADMIN` in a new user and network namespace.
* [CVE-2020-14386](https://nvd.nist.gov/vuln/detail/CVE-2020-14386): to exploit, need to interact with `AF_PACKET`, granted by `CAP_NET_RAW` in a new user namespace.
In a report from google [44% of the exploits](https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html) they saw required unprivileged user namespaces.
Because of this several distro kernels carry a patch that allows for a [sysctl to disable unprivileged user namespaces](https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction#disabling-unprivileged-user-namespaces) as a mitigation. Unfortunately the sysctl is all or nothing, disabling unprivileged user namespaces might stop an exploit but also can break applications that use them. Generally an exploit targets a specific application, and as long as unprivileged user namespaces can be disabled for those applications there is no need to disable them for the entire system.
With introduction of restricted unprivileged user namespaces AppArmor can be used to selectively allow and disallow unprivileged user namespaces. AppArmor policy is used to selectively control access to unprivileged user namespaces on a per applications basis.