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

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

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

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

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

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

Группа 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 (CVE-2019-5736 и CVE-2024-21626): оба давали root на хосте — потому что ядро одно на всех. Оба давно исправлены; важно вовремя обновляться.

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

Как закрыть

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

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

Контейнер — не виртуальная машина. Это процесс на том же ядре, что и хост, которому ядро показывает урезанную картину мира: свои идентификаторы процессов, свою сеть, свою файловую систему — это пространства имён (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. Дескриптор, указывающий в файловую систему хоста, оказался достижим изнутри — потому что ядро одно на всех.

Общее у обоих: ядро у контейнера и хоста одно, и отказ рантайма даёт к нему мост. Это и делает класс 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). У них своё гостевое ядро, граница с хостом — гипервизор с узким интерфейсом, и класс runc-побегов до хоста уже не доходит: пробивать нечего, общего ядра нет.

То же самое в 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, когда список нарушений пуст.

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

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

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

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

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

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

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