测验：最小权限

docker run --rm -v /etc:/host-etc alpine:3.20 sh -c 'echo "# injected" >> /host-etc/hosts'实际上修改的是hosts文件。最准确的解释是什么？

• 这是 Docker 守护进程中的一个已知错误，并且已在最新版本中被阻止。
• 该漏洞仅存在于高山图像中。
• >>只允许额外的重定向，防止覆盖。
• 如果不使用用户命名空间，则容器的 UID 0 与主机的 UID 0 相同，因此权限将应用于挂载的路径。

当我在 Dockerfile 中写入USER app时，Kubernetes 将 pod 拒绝为container has runAsNonRoot and image has non-numeric user (app), cannot verify user is non-root。正确的修复方法是什么？

• 将runAsNonRoot更改为 false
• 在 Pod 中指定runAsUser: 0
• 将/etc/passwd添加到图像中
• 将其指定为数字 UID，例如USER 10001:10001。

以非特权用户身份运行的服务必须打开端口 80。最简单且推荐的解决方案是什么？

• 将容器返回到根目录
• 将应用程序端口更改为8080，并在服务层将其公开为80。
• 添加--privileged
• 添加NET_BIND_SERVICE功能

以下哪一项不包含在容器的默认功能集中（大约 14 个）？

• CAP_SYS_管理员
• CAP_CHOWN
• CAP_SETUID
• CAP_NET_RAW

为什么在 CI 运行容器中安装 Docker 套接字（/var/run/docker.sock）实际上与--privileged具有相同的风险？

• 因为socket文件有setuid位
• 因为socket通信没有加密
• 这是因为可以启动在该套接字上安装了主机根文件系统的新特权容器。
• 因为docker套接字绕过了seccomp配置文件

CVE-2019-5736 和 CVE-2024-21626 之间最准确的相似度是多少？

• 两者都是运行时（runc）中的错误，但由于容器与主机位于同一内核下，因此导致了主机妥协。
• 两者都是内核漏洞
• 两者都是图像注册表的身份验证问题。
• 除非您关闭 seccomp 配置文件，否则这两种情况都不会发生