为什么要求在非根+不允许权限提升的库伯奈茨PodSecurityPolicy中删除所有功能？

Question

来自PodSecurityPolicy文档的第二个示例策略由以下PodSecurityPolicy片段组成

...
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
...

为什么对非root+不允许权限提升而放弃所有功能是多余的？您可以拥有一个没有权限提升的容器进程，它是非根的，但具有有效的功能，对吗？

在Docker看来，这是不可能的：

$ docker run --cap-add SYS_ADMIN --user 1000 ubuntu grep Cap /proc/self/status
CapInh: 00000000a82425fb
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000a82425fb
CapAmb: 0000000000000000

即使在试图显式添加它们时，所有有效的功能也已被丢弃。但是其他容器运行时可以实现它，所以这个评论只是特定于Docker吗？

Answer 1

为什么对非root+不允许权限提升而放弃所有功能是多余的？

由于您需要权限提升才能使用“新”功能，因此有效的allowPrivilegeEscalation: false将禁用训斥系统调用中的setuid，从而阻止任何新功能的使用。

另外，如文档中所示：“一旦设置了位，它就会被跨叉、克隆和execve继承，并且不能取消设置”。更多信息，这里。

这与privileged: false结合在一起，使requiredDropCapabilities: [ALL]变得多余。

这里的等效码头选项是：

• --user=whatever => privileged: false
• --security-opt=no-new-privileges => allowPrivilegeEscalation: false
• --cap-drop=all => requiredDropCapabilities: [ALL]

看来这在码头上是不可能的

这就是Docker正在做的事情，当您指定一个非特权用户时，所有的有效功能都会被删除(CapEff: 0000000000000000)，即使您指定了--cap-add SYS_ADMIN。

这与--security-opt=no-new-privileges作为一个选项结合在一起，使--cap-drop=all变得多余。

请注意，似乎码头的默认功能掩码包括SYS_ADMIN。

$ docker run --rm ubuntu grep Cap /proc/self/status
CapInh: 00000000a80425fb
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000
$ capsh --decode=00000000a82425fb
0x00000000a82425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_admin,cap_mknod,cap_audit_write,cap_setfcap

这就解释了为什么00000000a82425fb是相同的，而不指定任何--cap-add选项。

但是其他容器运行时可以实现它，所以这个评论只是特定于Docker吗？

我想，所以您可能会遇到privileged: false和allowPrivilegeEscalation: false不能有效地禁用功能的情况，这可能会被requiredDropCapabilities:删除(不过，我不明白为什么另一个运行时会想要更改Docker行为)。

Answer 2

在你的问题中有多个(好的)子问题。

我想集中讨论以下主要问题：

为什么对非root+不允许权限提升而放弃所有功能是多余的？

为了简单起见，我认为我们可以集中讨论不允许特权升级的部件，只需问：

当我们将allowPrivilegeEscalation: false 设置为PodSecurityPolicy?时，在幕后发生了什么？

从K8S文档中可以看到，“这个bool直接控制是否在容器进程上设置了no_new_privs标志”。

，那么如果设置此标志会发生什么呢？

引用内核文档的话说：“当设置此标志时，execve承诺不授予权限，不执行任何没有execve调用就无法完成的操作。

例如，setuid和setgid位将不再更改uid或gid；文件功能不会添加到允许的集合“。

换句话说，设置allowPrivilegeEscalation: false将导致所有功能被删除。

这就是为什么添加这个部分被认为是多余的原因：

 requiredDropCapabilities:
    - ALL

我希望这能简化一些事情。

我认为其他问题的答案在已被接受的答案中是非常清楚的，我没有什么可补充的。

注意:如果您正在运行内核>= 4.10，那么您可以在/proc/[pid]/status文件中看到线程的no_new_privs属性的值-在功能属性下面：

.
.
CapInh: 00000000a82425fb
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000a82425fb
CapAmb: 0000000000000000
NoNewPrivs: 0 <-----
.
.