❌ Миф: если контейнер запущен без root, он не сможет получить root на хосте

Привет! Запустили контейнер с USER 1000, убрали лишние capabilities и убедились, что внутри никто не работает от root. Выглядит безопаснее, но есть нюанс: UID 1000 внутри контейнера не всегда означает изоляцию от привилегий хоста.

👨‍💻 По умолчанию Docker может использовать те же UID и GID, что и хост. Поэтому процесс с UID 1000 внутри контейнера обращается к примонтированным файлам с правами UID 1000 на хосте.

⚡️ Допустим, в контейнер передали каталог через bind mount. Если у процесса есть права на запись, он сможет менять файлы в этом каталоге. И никакой root для этого не нужен.

🚨 Ещё интереснее с —privileged и опасными capabilities. Например, CAP_SYS_ADMIN открывает доступ к большому набору привилегированных операций. А если контейнеру передали Docker socket, процесс с доступом к нему может попросить Docker daemon создать новый контейнер с доступом к файловой системе хоста.

⚙️ Проверить настройки контейнера можно через:

docker inspect <container>

Посмотрите User, Privileged, CapAdd, Mounts и UsernsMode. Особенно внимательно — на bind mounts и /var/run/docker.sock.

⚪️ Отдельно стоит проверить user namespaces. При включённом remapping UID внутри контейнера сопоставляются с другими UID на хосте, что помогает ограничить последствия компрометации.

P.S. Запуск без root полезен и действительно снижает риски. Но права процесса, доступные mounts и настройки изоляции здесь важны не меньше самого UID.

#Мифы #Docker #Containers #Infosec

🤖Бесплатный ChatGPT