Вопрос или проблема
У меня есть смутное чувство, что существует широко распространенная проблема безопасности, которая остается незамеченной. Я пытаюсь выяснить, как проверить уровень актуальности и осведомленности в этом вопросе или как, возможно, повысить его.
Ситуация:
Когда вы используете GitLab CI с docker-executor, ‘git clone’ репозитория выполняется с umask 0000,
Что фактически делает весь клонируемый контент доступным для записи всем.
На мой взгляд, отгрузка этих файлов в таком виде довольно распространена и может создавать серьезные проблемы безопасности. (Смотрите ниже для деталей моей оценки)
При исследовании проблемы мы обнаружили:
- Что не очевидно отследить, почему пакет или образ, который вы отгружаете, внезапно содержит файлы с правами на запись для всех, когда он собирается через GitLab (но не тогда, когда собирается на вашей локальной системе разработки)
- Что такое поведение является стандартным и существует с конца 2015 года и что практически никто (кроме gitlab.com) об этом не говорит
- Что существует флаг функции для отключения этого (FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR) с конца 2020 года, но об этом тоже никто не говорит
Это оставляет мне 3 варианта, и я хочу выяснить, какой из них преобладает в большинстве случаев:
- Не является ли это неуместным (не проблемой безопасности) отгружать файлы с правами на запись для всех?
- Это не происходит? (Все, кто использует эту очень распространенную настройку, осведомлены об опасности и активно противодействуют ей?)
- Существуют ли множество пакетов приложений, образов Docker и т.д., где авторы не осведомлены о потенциальной проблеме?
Дополнительные детали моей оценки:
- Мне кажется, это очень актуально, потому что отгруженный код не должен быть доступен для записи всем пользователям на системе, так как это открывает широкий спектр векторов атак. Не так ли? (-> 1.)
- Если, например, вы создаете .deb-пакет из содержимого репозитория, это не останется незамеченным, и права на выходные файлы в конечном итоге будут скорректированы. Но когда вы создаете tar-файлы или образы Docker, это может оставаться довольно незамеченным. (-> 2.)
- Существуют ли поисковые системы/сервисы для широкого контроля прав на файлы на общих сайтах распределения пакетов/образов? (-> 3.)
Я могу ответить на вопрос 3 здесь, по поводу образов Docker. Обычно в образе Docker/контейнера работает одно приложение под одной учетной записью пользователя.
Образ будет иметь одну цель, а именно выполнять приложение, которое работает в этом образе, и мы ожидаем, что UID, запускающий приложение, имеет доступ к файлам в этом образе.
В этом случае, какова была бы польза от ограничения прав на файлы образа? Если целью было бы предотвратить возможность пользователю, запускающему приложение, изменения своих собственных файлов, то, как правило, лучший способ справиться с этим — просто установить, чтобы образ имел файловую систему только для чтения.
В общем, в Linux я бы сказал, что основной целью прав на файлы является возможность существования нескольких пользователей на хосте, не позволяя всем им иметь доступ к файлам друг друга. В среде, где есть только одна учетная запись пользователя, это было бы менее важно.
Также стоит отметить, что высокий процент образов Docker работает от имени root, где права на файлы не имеют особого значения.
Ответ или решение
Вопрос о том, имеет ли значение наличие файлов, доступных для записи всем пользователям (world-writable files), в контексте использования GitLab CI с docker-executor, действительно требует всестороннего анализа и повышения осведомленности среди разработчиков и администраторов.
Контекст проблемы
При использовании GitLab CI с docker-executor, процесс git clone репозитория выполняется с маской прав доступа umask 0000. Это приводит к тому, что все клонированные файлы становятся доступными для редактирования любому пользователю системы. На первый взгляд, это может показаться незначительной проблемой, но при более внимательном рассмотрении реальность оказывается более тревожной.
Аспекты проблемы
-
Безопасность
Использование world-writable файлов открывает дверь для множества потенциальных атак. Если зловредный пользователь или программа получает доступ к системе, они могут вносить изменения в любой файл, что может привести к компрометации данных и системной безопасности. Критически важно, чтобы финальные артефакты, такие как Docker-образы или пакеты, имели строгую политику прав доступа. В противном случае существует риск, что код, который должен оставаться неизменным, будет модифицирован, что может привести к уязвимостям и злоупотреблениям.
-
Понимание аудитории
Как отмечается, данная проблема не является широко обсуждаемой, что может свидетельствовать о том, что многие пользователи GitLab CI с docker-executor не осознают этого аспекта. Выявление и понимание данной уязвимости требует осведомленности в среде разработчиков и техников. Без должного внимания проблемы могут оставаться вне поля зрения, что увеличивает риски.
-
Реальные последствия
Хотя известны случаи, когда в пакетах, таких как .deb, проверки прав доступа проводятся более тщательно, то в случае с Docker-образами такое может оставаться без внимания. Следовательно, необходимо выявить и проанализировать, сколько образов и пакетов по существу вызывают проблемы с безопасностью из-за отсутствия должного контроля прав доступа.
Возможные варианты развития ситуации
Существует три основных сценария, в которых можно оценивать соответственно актуальность проблемы:
-
Незначительность проблемы: Можно предположить, что shipping world-writable файлов не является проблемой, если они не используются многими пользователями или если система конфигурируется так, что доступ к ним ограничен.
-
Осведомленность пользователей: Возможно, большинство пользователей в данной экосистеме осознают потенциальные риски и принимают меры для их устранения, например, изменяя umask или указывая права доступа в Dockerfile.
-
Недостаток знаний: Скорее всего, многие разработчики и руководители проектов не осознают, насколько критична эта проблема, оставляя свои артефакты с рисками.
Заключение и рекомендации
На основании вышеизложенного, стоит настоятельно рекомендовать:
-
Поднять осведомленность: Профессиональные сообщества, такие как GitLab и Docker, должны повысить осведомленность о данной проблеме, распространяя информацию через блоги, семинары, и на форумах. Мыть осуществлять адаптацию документации, чтобы она включала рекомендации по установке безопасности для umask.
-
Обратная связь от сообщества: Важно создать платформу для обсуждения такой проблемы, возможно, через GitLab или другие каналы, чтобы разработчики могли обмениваться опытом и лучшими практиками.
-
Инструменты для анализа: Реализовать сканеры, которые могли бы анализировать права доступа для пакетов и Docker-образов, чтобы обеспечить прозрачность и предотвратить потенциальные проблемы заранее.
Таким образом, важно не только осведомить общественность о потенциальных рисках, но и поощрять крупных участников отрасли начаться обсуждения и совместной работы над улучшением стандартов безопасности в использовании CI/CD-систем и Docker-приложений.