Почему требуется, чтобы все возможности были отброшены в избыточной базе данных Kubernetes PodSecurityPolicy с повышением привилегий без полномочий root + disallow?

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 + disallow?У вас может быть контейнерный процесс без повышения привилегий, который не является 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

Почему отбрасывание всех возможностей избыточно для некорневого + запрещение повышения привилегий?

Поскольку вам нужно повышение привилегий, чтобы иметь возможность использовать «новые» возможности, эффективно allowPrivilegeEscalation: falseотключает setuid в системном вызове execve , который запрещает использование каких-либо новых возможностей.Также, как показано в документации: «Как только бит установлен, он наследуется через fork, clone и execve и не может быть сброшен» .Подробнее здесь .Это в сочетании с privileged: false делает requiredDropCapabilities: [ALL] избыточным.

Эквивалентные опции Docker здесь:

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

Кажется, что это невозможно с Docker

Это похоже на то, что делает Docker, в тот момент, когда вы указываете непривилегированного пользователя, все эффективные возможности отбрасываются (CapEff: 0000000000000000), даже если вы указываете --cap-add SYS_ADMIN

Это в сочетании с --security-opt=no-new-privileges как опция отображает --cap-drop=all избыточный.

Обратите внимание, что похоже, что маска возможностей по умолчанию для Docker включает в себя 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)