首先，这里整合了来自以下地址的漏洞利用代码，并将其打包成一个便捷的预构建容器： https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555
预构建容器：quay.io/cgwalters/cve-2021-22555
一项强有力的缓解措施是启用 seccomp，并禁止 clone(CLONE_NEWUSER) 系统调用。上游 Kubernetes 文档 中提供了一些相关信息，但如何将策略部署到节点则留给了用户。在 OpenShift 4 中，我们拥有 machine-config-operator 来处理这项工作。
seccomp 在 官方文档 中并未得到充分讨论。不过，安全指南 至少提及了其中一部分，这篇博客 也是如此。
cri-o 在 4.7 版本中附带了一个默认的 seccomp 策略，但默认并未启用。
podman 和 docker 也都附带了一个策略，并且默认是启用的（但两者有所不同，详见下文）。
cri-o 的策略默认不会禁止 clone(CLONE_NEWUSER)——podman 的策略也是如此。然而，docker 的默认策略 确实禁止了 clone(CLONE_NEWUSER)：
[root@cosa-devsh ~]# rpm -q podman moby-engine
podman-3.1.2-1.fc33.x86_64
moby-engine-19.03.13-1.ce.git4484c46.fc33.x86_64
[root@cosa-devsh ~]# podman run --rm -ti registry.fedoraproject.org/fedora:34 /bin/sh -c 'unshare -U --keep-caps true'
[root@cosa-devsh ~]# echo $?
0
[root@cosa-devsh ~]# docker run --rm -ti registry.fedoraproject.org/fedora:34 /bin/sh -c 'unshare -U --keep-caps true'
unshare: unshare failed: Operation not permitted
errchan: json: cannot unmarshal array into Go struct field systemdEventMessage.MESSAGE of type string
[root@cosa-devsh ~]# echo $?
1
[root@cosa-devsh ~]#
换句话说：docker 默认不会受此漏洞影响，但 podman 和 cri-o 会。（待办：检查 containerd）
openshift/seccomp-for-fun-and-profit 博客条目讨论了其中的一些内容，并给出了作者生成的一个配置文件链接。该策略确实禁止了 clone(CLONE_NEWUSER)。
为方便起见，本仓库在 more-restricted.json 中包含了该配置文件的一个副本，以及一个 Butane 文件，该文件可生成一个 MachineConfig 对象，用于将该配置文件部署到工作节点。
使用 示例 pod 文件，其中包含：
securityContext:
seccompProfile:
type: Localhost
localhostProfile: more-restricted.json
我们得到：
$ oc logs pod/cve-2021-22555
[+] Linux Privilege Escalation by theflow@ - 2021
[+] STAGE 0: Initialization
[*] Setting up namespace sandbox...
[-] unshare(CLONE_NEWUSER): Operation not permitted
这应该能使漏洞利用无法进行。
然而，这需要 pod 主动选择加入。仍然待办：探索是否可以通过 SecurityContextConstraint 强制要求 seccomp 策略，或者是否需要使用一个可变准入 Webhook。