❌ Миф: если контейнер запущен без root, он не сможет получить root на хосте
❌ Миф: если контейнер запущен без 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