Побег из контейнера: как выходят на хост и как это закрыть

Контейнер — это не отдельная машина

Легко подумать, что контейнер — маленькая виртуальная машина. Это не так. Контейнер — обычный процесс на общем с хостом ядре. Ядро показывает ему свой кусочек: свои процессы, свою сеть, свою файловую систему. Но ядро — то же самое, что и у хоста. Изоляция контейнера — это разметка внутри одной квартиры, а не отдельный дом.

Из этого следуют два очень разных способа «сбежать» из контейнера на хост.

Способ первый: ключи отдали сами

Чаще всего никто ничего не ломает — доступ к хосту выдали настройками.

Группа docker — это root. Демон Docker работает от root, и кто может им командовать, тот управляет хостом. Документация Docker прямо просит пускать к демону только доверенных людей. А запустить контейнер с примонтированным корнем хоста — штатная возможность:

docker run -v /:/host --rm -it alpine chroot /host sh
# это root-шелл в файлах хоста

Ничего не взломано: команда сделала то, что обещано. Поэтому добавить человека в группу docker — всё равно что выдать ему sudo без пароля.

Проброшенный сокет и --privileged — то же самое, только в другой форме. Если в контейнер пробросили /var/run/docker.sock, изнутри можно командовать демоном хоста. Флаг --privileged снимает почти все ограничения контейнера. И то и другое — открытая дверь, а не взлом.

Способ второй: ошибка в общем рантайме

Это уже настоящий побег: не открытую дверь нашли, а пробили стену. Рантайм runc работает на хосте с правами root и сам собирает контейнер, поэтому ошибка в нём даёт выход наружу; ошибка в общем ядре — другой путь с тем же итогом. Так работали два известных бага в runc (CVE-2019-5736 и CVE-2024-21626): первый давал root на хосте, второй — рабочий каталог в файловой системе хоста, а по описанию самого проекта его последствия доходили до полного побега. Оба давно исправлены; важно вовремя обновляться.

Картинка ниже показывает две модели рядом — контейнер с общим ядром и микро-VM с гипервизором — и какую границу пробивает каждый класс.

Как закрыть

• Не раздавать ключи. Группа docker — только доверенным; не пробрасывать docker.sock; убрать --privileged.
• Сузить права. Работать под непривилегированным пользователем, сбросить лишние привилегии, включить rootless-режим — тогда даже побег не даёт root на хосте.
• Обновлять runc и не выключать защиту ядра (seccomp, AppArmor/SELinux).
• Для недоверенного кода — другая граница. gVisor, Kata или микро-VM (Firecracker): системные вызовы кода обслуживает их собственное ядро (у gVisor — в пользовательском пространстве, у Kata и Firecracker — за гипервизором), и путь runc-побегов упирается в него, а не в хост. Но у этой границы свои компоненты (у gVisor — Sentry, у микро-VM — гипервизор и VMM), и ошибка в них — тоже путь наружу: их тоже обновляют.

Что такое контейнер и где у него граница

Контейнер — не виртуальная машина. Это процесс на том же ядре, что и хост, которому ядро показывает урезанную картину мира: свои идентификаторы процессов, свою сеть, свою файловую систему — это пространства имён (namespaces). Сколько ресурсов ему можно брать, решают контрольные группы (cgroups). Что ему позволено делать в ядре, ограничивает набор привилегий (capabilities).

Ключевое здесь — слово «общее». Все три механизма живут в одном ядре с хостом. Поэтому изоляция контейнера — это не стена виртуальной машины, а разметка внутри одной квартиры. NIST в руководстве по безопасности контейнеров прямо признаёт их границу слабее, чем у гипервизора. Из этого и растут оба класса побега: где-то разметку отдали добровольно, где-то её пробила ошибка.

Что здесь считается доверенным

До перечня защит стоит договориться о рамке, иначе спор «безопасен ли контейнер» не имеет ответа. NIST в руководстве по безопасности контейнеров рамку задаёт дважды.

Первое — про класс границы, и сказано это прямо:

Причина названа там же, в разделе про общее ядро:

Второе — о том, где документ проводит границу собственного рассмотрения. Это ровно тот список, который стоит держать в голове, читая любые обещания изоляции:

Отсюда практический вывод, который и есть модель угроз в одну строку: всё, что делит с вами ядро, считайте одинаково доверенным. Не «изолированным», а именно доверенным — потому что граница между ними слабее той, что даёт гипервизор, и настраивается она вами, а не производителем.

Из этого же следует, что рантайм — часть границы. Прямого требования «держите рантайм свежим» в документе нет; есть две соседние формулировки, из которых оно выводится. Уязвимость рантайма ведёт к побегу: While relatively uncommon, vulnerabilities within the runtime software are particularly dangerous if they allow "container escape" scenarios (Хотя это относительно редко, уязвимости в программном обеспечении рантайма особенно опасны, если они допускают сценарии „побега из контейнера“). И отсюда обязанность: The container runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly (Рантайм контейнеров должен внимательно отслеживаться на предмет уязвимостей, и при обнаружении проблем они должны устраняться быстро).

А из «одинаково доверенного» следует правило размещения, названное в документе явно:

То есть решение «где это запускать» принимается не после настройки, а до неё: по тому, совпадают ли назначение, чувствительность и модель угроз у соседей.

Класс 1: побег, которого не было, — розданные ключи

Самая частая «дыра» — не дыра. Управление хостом отдали через конфигурацию, и атакующему остаётся им воспользоваться. Разберём три типовых случая; во всех трёх изоляция ядра ни при чём.

Группа docker — это root на хосте

Демон Docker работает от root. Тот, кто может отдавать ему команды, фактически управляет хостом. Документация Docker говорит это прямо: Only trusted users should be allowed to control your Docker daemon (Управлять демоном Docker должно быть позволено только доверенным пользователям). Членство в группе docker даёт ровно такое управление — без sudo, без пароля.

Почему это равно root, видно из другого места той же документации. Docker позволяет смонтировать любой каталог хоста внутрь контейнера без ограничения прав: you can start a container where the /host directory is the / directory on your host; and the container can alter your host filesystem without any restriction (вы можете запустить контейнер, в котором каталог /host — это корень / файловой системы хоста; и контейнер сможет менять её без каких-либо ограничений). То есть тот, кто может запустить контейнер, может смонтировать корень хоста и писать в него:

docker run -v /:/host --rm -it alpine chroot /host sh
# теперь это root-шелл в файловой системе хоста

Это не эксплойт и не уязвимость — это задокументированное поведение. Никакой механизм изоляции здесь не отказывал: команда сделала ровно то, что обещано. Поэтому группа docker — не «удобство для разработчика», а раздача root, и относиться к ней надо как к выдаче sudo без пароля.

Проброшенный сокет docker.sock

То же самое, но изнутри контейнера. Если в контейнер пробросили /var/run/docker.sock (частый приём для CI и «Docker-in-Docker»), процесс внутри получает канал к демону хоста — а значит, те же возможности, что даёт группа docker: может запросить новый контейнер с примонтированным /. OWASP выносит это в правило номер один: Do not expose the Docker daemon socket (even to the containers) (Не открывайте сокет демона Docker (даже контейнерам)) — Giving someone access to it is equivalent to giving unrestricted root access to your host (Дать кому-то доступ к нему — то же самое, что дать неограниченный root на хосте).

--privileged и лишние capabilities

Флаг --privileged снимает почти все ограничения: отдаёт контейнеру полный набор capabilities и доступ к устройствам хоста, отключает профили seccomp и AppArmor. Из такого контейнера до хоста рукой подать. То же относится к отдельным опасным привилегиям вроде CAP_SYS_ADMIN и к монтированию хостовых путей. OWASP: Do not run containers with the --privileged flag (Не запускайте контейнеры с флагом --privileged).

Вывод по классу 1: большинство «побегов из контейнера» в реальных инцидентах относятся именно к нему. Ломать ядро не требуется, потому что доступ к хосту выдали конфигурацией. Хорошая новость: и закрывается он конфигурацией — об этом ниже.

Класс 2: настоящий побег — ошибка в общем рантайме или ядре

Теперь о побеге в строгом смысле: атакующий пересекает границу, которую никто не открывал. Раз ядро и рантайм общие с хостом, ошибка в них даёт мост наружу. Ниже два известных примера — только описание того, что именно отказало, без шагов воспроизведения.

CVE-2019-5736. Дословно: runc through 1.0-rc6 … allows attackers to overwrite the host runc binary (and consequently obtain host root access) (runc вплоть до 1.0-rc6 … позволяет злоумышленнику перезаписать исполняемый файл runc на хосте (и тем самым получить на хосте права root)). Отказал не механизм изоляции ядра, а runc — рантайм, общий для контейнера и хоста. Перезаписав его, можно было получить root на хосте.

CVE-2024-21626. Дословно: due to an internal file descriptor leak, an attacker could cause a newly-spawned container process … to have a working directory in the host filesystem namespace (из-за внутренней утечки файлового дескриптора злоумышленник мог добиться того, чтобы у только что запущенного процесса контейнера … рабочий каталог оказался в пространстве имён файловой системы хоста). Снова рантайм; исправлено в runc 1.1.12. Дескриптор, указывающий в файловую систему хоста, оказался достижим изнутри — потому что ядро одно на всех.

Общее у обоих: отказала не изоляция ядра, а рантайм — программа, которая работает на хосте с правами root и сама готовит процесс контейнера. Ошибка рантайма и уязвимость ядра — разные механизмы, и одной фразой «потому что ядро общее» их не объяснить. Объединяет их другое: у обычного контейнера и рантайм, и ядро хоста входят в доверенную базу, и ошибка в любом из них ведёт к хосту. Поэтому защита от класса 2 — не только патчи, но и выбор границы: какие компоненты окажутся между недоверенным кодом и хостом (последний блок раздела «Как это закрыть»).

Как это закрыть

Защита эшелонирована: сначала не раздавать доступ (класс 1), потом сузить то, что осталось, и наконец — для недоверенного кода — поставить между ним и ядром хоста другую границу (класс 2). Правила ниже — из OWASP Docker Security Cheat Sheet и документации Docker.

Не раздавать управление демоном.

• Группа docker — только доверенным людям; членство в ней приравнять к sudo и регулярно проверять.
• Не пробрасывать /var/run/docker.sock в контейнеры; не открывать демон по TCP.
• Rootless-режим: демон и контейнеры работают от непривилегированного пользователя, и тогда даже побег из контейнера не даёт root на хосте.

Сузить привилегии контейнера.

• Никакого --privileged. Сбросить все capabilities и вернуть только нужные.
• Работать под непривилегированным пользователем внутри контейнера — OWASP называет это лучшим способом против повышения привилегий.
• --security-opt=no-new-privileges — чтобы setuid-бинарники не поднимали права.
• --read-only для корневой ФС там, где это возможно.

Оставить включённой защиту ядра.

• Не выключать профиль seccomp по умолчанию; держать AppArmor или SELinux.
• Включить user namespaces: root внутри контейнера перестаёт быть root на хосте.

Против класса 2 — патчи и другая граница.

• Обновлять рантайм: держать runc на текущем патч-релизе своей ветки и читать бюллетени безопасности проекта. Конкретный номер здесь называть бессмысленно: он меняется с каждым бюллетенем, и вчерашнее «достаточно свежо» сегодня уже уязвимо.
• Для недоверенного кода — сменить границу: gVisor (перехват системных вызовов), Kata Containers или микро-VM (Firecracker). Системные вызовы кода обслуживает уже не ядро хоста напрямую: у gVisor — Sentry, ядро в пользовательском пространстве, у Kata и Firecracker — гостевое ядро за гипервизором. Путь, которым шли runc-побеги, упирается тогда в эту промежуточную границу, а не в хост. Но граница не исчезает, она меняется: Sentry сам обращается к ядру хоста через ограниченный набор вызовов, а у микро-VM остаются VMM, виртуальные устройства и компоненты на стороне хоста. Ошибка в них — тоже путь наружу, поэтому их так же обновляют и запускают с минимальными правами, а выбор делают по модели угроз.

То же самое в Kubernetes: три уровня и что каждый запрещает

Всё вышесказанное про флаги docker run в Kubernetes выражается декларативно, и перечень не надо составлять самому: он стандартизован тремя политиками.

Слово «накопительные» здесь рабочее: Restricted включает всё из Baseline.

Privileged — это отсутствие ограничений, и документация этого не смягчает: Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations (Неограничивающая политика, дающая максимально широкий уровень разрешений. Эта политика допускает известные способы повышения привилегий). Она предназначена для системных нагрузок, которыми управляют доверенные люди, — то есть для того самого случая «ключи розданы намеренно» из первого класса выше.

Baseline — Minimally restrictive policy which prevents known privilege escalations (Минимально ограничивающая политика, которая предотвращает известные способы повышения привилегий). Пять её пунктов один в один ложатся на раздел «Как это закрыть» — те же запреты, записанные полями манифеста (всего проверок в политике больше, здесь — только совпадающие):

Разрешённый Baseline список capabilities — тринадцать имён: AUDIT_WRITE, CHOWN, DAC_OVERRIDE, FOWNER, FSETID, KILL, MKNOD, NET_BIND_SERVICE, SETFCAP, SETGID, SETPCAP, SETUID, SYS_CHROOT.

Restricted — Heavily restricted policy, following current Pod hardening best practices (Сильно ограничивающая политика, следующая текущим практикам ужесточения Pod), и добавляет она то, что выше названо «сузить привилегии»:

Обратите внимание на разницу в строке про seccomp: Baseline запрещает выключить профиль, Restricted требует выставить его явно — отсутствие профиля тоже запрещено. Это разные требования, и второе сильнее.

Семантику полей стоит взять из типов API, а не из пересказов. Два места, где чаще всего ошибаются:

То есть выставить allowPrivilegeEscalation: false и одновременно оставить привилегированный режим нельзя: второе побеждает молча.

runAsNonRoot: true — это проверка, а не назначение пользователя. Образ, собранный под root, с ней не запустится; пользователя надо задать в образе или через runAsUser.

Как это включается. Политики применяются метками пространства имён — pod-security.kubernetes.io/<режим>: <уровень>, — и режимов три: enforce (Policy violations will cause the pod to be rejected (Нарушения политики приведут к отклонению Pod)), audit и warn. Порядок внедрения отсюда очевиден: сначала warn и audit, а enforce — когда список нарушений опустеет.

И то, чем меняют границу для второго класса. Поставить недоверенный код за gVisor или гипервизор в Kubernetes — это не отдельная инфраструктура, а поле в манифесте: RuntimeClass стабилен с версии 1.20.

Это ровно то же решение, что и «gVisor или Kata для недоверенного кода» из предыдущего раздела, только принимаемое на уровне отдельного Pod, а не всего узла. И принимается оно по тому же правилу, что и в модели угроз выше: по совпадению назначения, чувствительности и модели угроз.

Что стоит унести

«Побег из контейнера» — это чаще всего не взлом, а раздача прав. Прежде чем думать про CVE, проверьте конфигурацию: кто в группе docker, где проброшен сокет, где стоит --privileged. Класс 1 закрывается гигиеной, а не патчами.

Группа docker = root на хосте. Это документированное поведение, а не уязвимость. Выдавать её — то же, что выдавать sudo без пароля.

Настоящий побег — ошибка в доверенной базе: рантайме или ядре. Патчи (runc, ядро) закрывают известные дыры, а следующие возможны. Другая граница — gVisor, Kata, микро-VM — сужает прямой доступ к ядру хоста и рвёт конкретный путь runc-побегов, но приносит свою доверенную базу (Sentry, VMM), которую тоже обновляют и ограничивают в правах.

Спрашивайте не «сломают ли контейнер», а «что мы сами отдали и какая граница защищает остальное». У обычного контейнера это разметка на общем ядре; у микро-VM — гостевое ядро и гипервизор с более узким интерфейсом к хосту. Более узкий — не значит пустой: какую поверхность оставить, решает модель угроз.