Update unprivileged_userns_restriction

John Johansen 2022-10-25 06:45:56 +00:00
parent 3cd17c3558
commit dea94c9538

@ -2,8 +2,6 @@
Unprivileged user namespaces are a feature of the kernel that can be used to replace many of the uses of setuid and setguid programs, and also allow for applications to create more secure sandboxes.
to create semiprivileged processes that can replace the use of setuid and setguid binaries. The processes wit
However while unprivileged user namespaces have been beneficial by reducing the need for setuid and setguid processes they expose kernel interfaces that are normally restricted to processes with privileged capabilities (root) to use by unprivileged users. Exposing more kernel interfaces than necessary to a process introduces additional security risks, and unfortunately unprivileged user namespaces are now broadly used as a step in several privilege escalation exploit chains. Basically even if unprivileged user namespaces are bug free, as long as any privileged kernel interface or combination of interfaces has a bug an unprivileged user can try to exploit that bug.
This has lead to many real world CVEs. Examples (to pick a few):
@ -15,7 +13,7 @@ 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.
Because of this several distro kernels carry a patch that allows for a sysctl to disable unprivileged user namespaces as a mitigation. Unfortunately the sysctl is all or nothing, disabling unprivileged 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 not need to disable them for the entire system.
Because of this several distro kernels carry a patch that allows for a sysctl to disable 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. ?? default deny
@ -30,6 +28,8 @@ unprivileged_userns_clone
cat /proc/sys/kernel/unprivileged_userns_clone
to create semiprivileged processes that can replace the use of setuid and setguid binaries. The processes wit
@ -37,7 +37,7 @@ cat /proc/sys/kernel/unprivileged_userns_clone
There are two ways to determine if your Kernel has support for restricting unprivileged user namespaces
## Looking in /proc
## Examine /proc
If the file
@ -47,7 +47,7 @@ If the file
exists your kernel supports restrictions on unprivileged user namespaces
## apparmor
## Examine AppArmor features
The presence of AppArmor's ability to control user namespaces can also be found by introspecting AppArmor's advertised feature set via the following command
@ -62,11 +62,13 @@ If the value ```userns_create``` is present AppArmor can control the creation of
# Audit message
If AppArmor denies an unconfined unprivileged process from creating a user namespace it log would a message to the Audit subsystem. Similar to the following example message.
```
apparmor="DENIED" operation="userns_create" class="namespace" info="User namespace creation restricted" error=-13 profile="unconfined" pid=21323 comm="steamwebhelper" requested="userns_create" denied="userns_create"
```
# controlling unprivileged user namespace restrivtions via sysctl
# Controlling unprivileged user namespace restrivtions via sysctl
apparmor_restrict_unprivileged_userns
@ -80,7 +82,7 @@ apparmor_restrict_unprivileged_userns
##
# policy
# Allowing user namespaces creation in policy
When restrictions on unprivileged user namespaces are enabled unconfined unprivileged processes are not allowed to create user namespaces. Unconfined unprivileged processes must be confined by a profile to be able to create user name spaces when restrictions on unprivileged user namespaces are enabled.