Вопрос или проблема
Это вопрос для обратной связи, чтобы выяснить, имеет ли проблема широкое воздействие.
Ситуация:
При использовании GitLab CI с docker-executor, ‘git clone’ используемого репозитория выполняется с umask 0000,
Что фактически делает весь клонированный контент доступным для записи любому пользователю.
Отправка этих файлов как есть (например, в образах docker) может потенциально создать огромные проблемы с безопасностью, в зависимости от программного обеспечения.
По крайней мере, в нашем случае, рабочий процесс
GitLab CI -> docker-executor -> сборка и загрузка образа docker из репозитория
является преобладающим, и мы в итоге получили образы docker, содержащие код, доступный для записи всем пользователям.
Исследуя эту проблему, мы обнаружили:
- Что это существует с конца 2015 года и практически никто об этом не говорит
- Что существует флаг функции, чтобы отключить это (FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR) с конца 2020 года, но никто и об этом не говорит
Это оставляет нам 3…
Вопрос(ы):
- Никто не использует GitLab таким образом?
- Все всегда устанавливают права доступа (chmod) ко всем содержимым из репозиториев / на выходе?
- Существуют ли различные дистрибутивы программного обеспечения с кодом, доступным для записи всем пользователям?
Ответ или решение
На вопрос о том, все ли осведомлены о том, что GitLab CI с использованием docker-executor производит файлы с правами доступа, позволяющими запись для всех пользователей, следует ответить с учетом нескольких ключевых аспектов, о которых упоминается в вашем описании ситуации.
1. Ситуация
Когда GitLab CI использует docker-executor, процесс «git clone» выполняется с umask 0000. Это означает, что все клонированные файлы становятся доступными для записи любому пользователю системы. Эта проблема является важной, так как создание и развертывание Docker-контейнеров с такими свойствами может привести к серьезным проблемам безопасности, особенно если код, размещаемый в контейнерах, затем используется в производственных средах.
2. Исторический контекст
Данная проблема не является новинкой — она существует с конца 2015 года. Интересно, что, несмотря на потенциальные уязвимости, обсуждение данной проблемы в сообществе GitLab является весьма ограниченным. Появление флага функции для отключения этой настройки (FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR) в 2020 году также не привлекло должного внимания, что наводит на мысль о том, что многие пользователи GitLab могли просто не знать о возможных рисках, связанных с использованием конфигурации по умолчанию.
3. Возможные проблемы и риски
Возникает ряд вопросов, на которые стоит обратить внимание:
- Использует ли кто-то GitLab с таким конфигом? Вероятно, многие пользователи могут не знать о данной проблеме или полагаться на другие механизмы безопасности, что может привести к игнорированию серьезных уязвимостей.
- Часто ли пользователи вручную изменяют права доступа на файлы? Если пользователи GitLab действительно не знают о вопросах безопасности, то ручная команда
chmodможет не быть частью их процессинга, что увеличивает риски. - Существует ли множество программных дистрибутивов с файлами, доступными для записи? Это очень вероятно, и в этом случае конечные пользователи могут оказаться в уязвимом положении, если программные обеспечивающие компании не уделяют должного внимания этому аспекту.
Заключение
Основная тревога заключается в том, что многие пользователи GitLab CI, особенно те, кто использует docker-executor, могут не осознавать, что их контент потенциально является уязвимым. Это может привести к серьезным уязвимостям в развертывании и эксплуатации программного обеспечения, поставляемого в Docker-образах. Осведомленность о данной проблеме и ее решение должны стать приоритетом для разработчиков и системных администраторов, использующих GitLab, особенно в контексте продакшн-сред. Важно продолжать диалог в сообществе, чтобы предотвратить возможные угрозы и обеспечить высокие стандарты безопасности цифровых решений.