hostPID: true и --pid=host Два параметра, указанных выше приводят к запуску контейнеров в PID-неймспейсе хоста в kubernetes и docker соответственно. Запуск в PID-неймспейсе хоста позволяет получать доступ ко всем процессам хоста. Но вот какой доступ? Давайте разбираться. Во-первых, можно делать ps и посмотреть список процессов с параметрами командных строк. Во-вторых, можно обращаться к файловой системе /proc/PID/* других процессов. Тут неочевидный момент - при доступе к интересным файлам, например к /proc/PID/environ (содержащим весь environment процесса), ОС проверяет ptrace access mode. Подробно эта проверка описана в конце мана ptrace . Выпишу основное. Есть два уровня доступа: - менее привилегированный PTRACE_MODE_READ - более привилегированный PTRACE_MODE_ATTACH Полный список файлов в /proc/PID/ с указанием того какой уровень доступа к ним требуется перечислен в мане proc Базовая проверка для обоих уровней доступа на уровне ОС делается примерно одинаково, основное: - наборы UID и GID запрашивающего и целевого процесса должны совпадать - набор permitted capabilities целевого процесса должен быть подмножеством набора effective capabilities запрашивающего процесса - наличие у запрашивающего процесса CAP_SYS_PTRACE позволяет обойти указанные выше ограничения Также в проверке могут участвовать LSM, например apparmor и yama (последний работает только для PTRACE_MODE_ATTACH), но это мы рассмотрим в следующем посте. CAP_SYS_PTRACE тоже рассмотрим отдельно, с ним тоже есть тонкости. А вот что мы можем делать если у нас нет CAP_SYS_PTRACE? Так вот, немного утрируя мы можем получить доступ уровня PTRACE_MODE_READ во все контейнеры, запущенные с таким же набором capabilities, как и наш, или более узким, а также они должны быть запущены под тем же UID. Но это ведь обычная история в kubernetes/docker, там все контейнеры/поды как правило стартуют с одним и тем же набором capabilities и зачастую от одинакового пользователя (ниже считаем что это root). Из интересного можно читать /proc/PID/environ, но даже не это самое прикольное. Под PTRACE_MODE_READ также подпадают /proc/PID/root и /proc/PID/cwd. C их помощью мы можем попасть в файловую систему целевого контейнера. И если мы root, то мы в ней можем не только читать но и писать туда! И это без CAP_SYS_PTRACE и с apparmor/yama запущенными по умолчанию! А значит мы можем: 1) читать SA-токены из других подов /proc/PID/root/var/run/secrets/kubernetes.io/serviceaccount/token 2) попытаться добиться RCE в другом поде путем записи в /etc/ld.so.preload, /root/.ssh/authorized_keys, /etc/crontab и т.д. и т.п.