Огляд засобів захисту контейнерів

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Найважливіша ідея в hardening контейнерів полягає в тому, що не існує одного контролю під назвою “container security”. Те, що люди називають container isolation, насправді є результатом одночасної роботи кількох механізмів безпеки та управління ресурсами в Linux. Якщо документація описує лише один із них, читачі, як правило, переоцінюють його силу. Якщо документація перераховує всі без пояснення їх взаємодії, читач отримує каталог назв, але не реальну модель. Цей розділ намагається уникнути обох помилок.

У центрі моделі — namespaces, які ізолюють те, що може бачити workload. Вони дають процесу приватний або частково приватний вигляд файлових монтувань, PIDів, мережі, IPC-об’єктів, hostname-ів, відображень user/group, шляхів cgroup і деяких годинників. Але самі по собі namespaces не визначають, що процесу дозволено робити. Тут вступають у гру наступні шари.

cgroups регулюють використання ресурсів. Вони не є в першу чергу межею ізоляції в тому самому сенсі, що mount або PID namespaces, але операційно вони критично важливі, оскільки обмежують пам’ять, CPU, PIDs, I/O та доступ до пристроїв. Вони також мають безпекове значення, оскільки історично техніки виходу використовували записувані можливості cgroup, особливо в середовищах cgroup v1.

Capabilities розбивають стару всевладну модель root на менші одиниці привілеїв. Це фундаментально для контейнерів, оскільки багато workload-ів досі запускаються як UID 0 всередині контейнера. Тому питання полягає не просто в “чи є процес root?”, а скоріше в “які capabilities пережили, всередині яких namespaces, під якими обмеженнями seccomp і MAC?” Ось чому root-процес в одному контейнері може бути відносно обмеженим, тоді як root-процес в іншому контейнері на практиці може майже не відрізнятися від host root.

seccomp фільтрує syscalls і зменшує surface атаки ядра, який відкритий для workload. Часто саме цей механізм блокує очевидно небезпечні виклики, такі як unshare, mount, keyctl або інші syscalls, що використовуються в ланцюгах виходу. Навіть якщо процес має capability, яке в іншому випадку дозволило б операцію, seccomp все одно може заблокувати шлях syscall до того, як ядро повністю його обробить.

AppArmor і SELinux додають Mandatory Access Control поверх звичайних перевірок файлової системи та привілеїв. Вони особливо важливі, тому що продовжують мати значення навіть коли контейнер має більше capabilities, ніж йому слід дозволяти. Workload може мати теоретичне привілейоване право спробувати дію, але все одно бути забороненим від її виконання через свій label або profile, які забороняють доступ до відповідного шляху, об’єкта або операції.

Нарешті, існують додаткові шари підвищення безпеки, яким приділяють менше уваги, але які регулярно впливають на реальні атаки: no_new_privs, masked procfs paths, read-only system paths, read-only root filesystems і обережні runtime defaults. Ці механізми часто зупиняють “останню милю” компрометації, особливо коли атакуючий намагається перетворити виконання коду на ширше підвищення привілеїв.

Решта цієї папки пояснює кожен із цих механізмів детальніше, включно з тим, що саме робить відповідний примітив ядра, як спостерігати це локально, як його використовують поширені runtimes і як оператори випадково послаблюють його.

Namespaces

CGroups

Capabilities

Seccomp

AppArmor

SELinux

No New Privileges

Masked Paths

Read Only Paths

Багато реальних втеч також залежать від того, який контент хоста був змонтований у workload, тож після прочитання основних засобів захисту корисно продовжити з:

Sensitive Host Mounts

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks