Update unprivileged_userns_restriction

unprivileged_userns_restriction.md

@@ -15,16 +15,7 @@ This has lead to many real world CVEs. Examples (to pick a few):
 
 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. ?? default deny
-
-
-
-
-
-
-unconfined processes with capability SYS_ADMIN will 
-
-
+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.
 
 
 
@@ -106,7 +97,7 @@ To Enable
 
 # 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.
+When restrictions on unprivileged user namespaces are enabled unconfined unprivileged processes are not allowed to create user namespaces. Specifically unconfined processes that do not have CAP_SYS_ADMIN must be confined by a profile to be able to create user name spaces when restrictions on unprivileged user namespaces are enabled.
 
 Confined processes whether privileged or unprivileged are by default also not allowed to create user namespaces. To enable them to create user namespaces the following rule should be add to the applications profile.
 
@@ -114,6 +105,54 @@ Confined processes whether privileged or unprivileged are by default also not al
   allow userns create,
 ```
 
+## how this interacts with policy ABIs
+
+The user naemspace control respects policy ABIs. This means confined applications with ABIs that did not support control of user namespaces will function unchanged on kernels that support restrictions on user namespaces. The net effect is these profiles can be user to by-pass user namespace controls. This behavior can be overriden by using ABI pinning.
+
+### AppArmor 2.x
+To pin the abi of AppArmor 2.x policy add the following rule to the ```/etc/apparmor/parser.conf``` file.
+
+```
+policy-features=kernel
+```
+
+this will force AppArmor 2.x policy to use the current kernels ABI. Note that this may cause failures beyond controling user namespace. The ```kernel``` keyword can be replaced by a path to any appropriate ABI file, resulting in forcing that particular ABI to be used.
+
+### AppArmor 3.x
+
+AppArmor 3.x policy uses ABI rules in policy to indicate what ABI the policy was authored under. There are two ways to have this policy to enforce user namespace controls.
+
+#### Update policy ABI rules
+
+Policy ABI kernels can be updated to point to an ABI file that supports user namespace controls.
+
+Eg.
+
+```
+   abi <abi/3.0>,
+```
+
+can be changed to (assuming the file is available)
+
+```
+abi <abi/4.0>,
+```
+
+#### Pin an override ABI
+
+ABI rules can be overridden using a special override pin similar to the pin used with AppArmor 2.x policy. To do this the following rule is added to the ```/etc/apparmor/parser.conf``` file.
+
+```
+override-policy-abi=kernel
+```
+
+this will force AppArmor 2.x and AppArmor 3.x policy to use the current kernels ABI. Note that this may cause failures beyond controling user namespace. The ```kernel``` keyword can be replaced by a path to any appropriate ABI file, resulting in forcing that particular ABI to be used.
+
+
+#### Update/Replace the ABI file
+
+This method is NOT recommended, as policy references to such a modified ABI file will not be universally consistent. The basic idea is you can insert the correct ABI info in the ABI file or completely over write the ABI file with a new file. The particulars are omitted as if you don't know how to do this you should not do it.
+
 # Disabling unprivileged user namespaces
 
 Several distro kernels (but not all) have the ability to disable unprivileged user namespaces for the entire system via the ```unprivileged_userns_clone``` sysctl. If a kernel has this ability the file ```/proc/sys/kernel/unprivileged_userns_clone``` will be present. The current state of whether unprivileged user namespaces are allowed can be found by doing