Вопрос или проблема
Etckeeper отличен, но из документации неясно, как безопасно проверить коммит или ветку напрямую в /etc. Проблема в том, что при выполнении checkout git не учитывает метаданные и разрешения, и вам придется восстанавливать их с помощью команды etckeeper init позже. Он берет их из файла .etckeeper. Это означает, что до этого момента согласительная информация может быть раскрыта и прочитана всеми пользователями в системе.
Вот соответствующая часть документации:
Вы можете использовать любые команды git, которые вам нравятся, но имейте в виду, что если вы проверяете другую ветку или старую версию, git работает непосредственно с /etc вашей системы. Если вы решите проверить ветку или тег, убедитесь, что вы снова запускаете “etckeeper init”, чтобы получить любые изменения метаданных:
git checkout april_first_joke_etc
etckeeper init
А вот из ответа на форуме etckeeper, который добавляет к моей путанице:
etckeeper init восстанавливает разрешения файлов только при запуске в существующем
репозитории.Обратите внимание, что существует окно, в течение которого файлы, которые должны быть
частными, могут быть раскрыты, в зависимости от вашего umask, прежде чем
разрешения будут исправлены. Так что я не могу полностью рекомендовать делать это.
Вопрос в том: хватит ли добавления небольшого шага установки umask 077 на время перед выполнением checkout?
umask 077
git checkout april_first_joke_etc
etckeeper init
umask 022 # или что-то еще, что было раньше, или просто выйти из текущей сессии
Ответ или решение
Безопасный Чек-аут Коммитов с использованием Etckeeper: Подход и Рекомендации
Введение
Работа с конфигурационными файлами системы, особенно в директории /etc, требует осторожности, особенно когда используется система контроля версий, такая как Git, в сочетании с утилитой Etckeeper. Вопрос, рассматриваемый в данной статье, касается безопасного выполнения операции check-out в Etckeeper, минимизации рисков утечки конфиденциальной информации и учета метаданных и разрешений файлов.
Проблема безопасности
Как указано в документации Etckeeper, при выполнении команды git checkout Git не сохраняет метаданные файлов, такие как их разрешения. Это создает потенциальный риск, так как файлы, содержащие чувствительную информацию, становятся доступными для сервиса до тех пор, пока не будет выполнена команда etckeeper init. Это означает, что на переходный период файлы могут быть уязвимы и доступны для несанкционированного доступа.
Рекомендация по управлению umask
Автор вопроса предложил установить umask 077 перед выполнением коммита, чтобы обеспечить дополнительные уровни безопасности. Данная идея имеет право на жизнь, поскольку устанавливая umask на 077, вы ограничиваете разрешения на создаваемые или измененные файлы, разрешая доступ только владельцу. Однако, стоит обратить внимание на следующие моменты:
-
Шаги выполнения:
umask 077 # Установка временного umask git checkout branch_name # Чек-аут нужной ветки etckeeper init # Восстановление метаданных и разрешений umask 022 # Восстановление предыдущих настроек umask -
Временная уязвимость:
Несмотря на использование umask, существуют другие потенциальные уязвимости, такие как возможность других процессов (или пользователей) в системе взаимодействовать с файлами в момент их расшаривания. Поэтому, при возможности, лучше всего всегда выполнять действия с/etcв период, когда доступ к системе ограничен (например, в режиме одиночного пользователя или при временном отключении сетевых интерфейсов). -
Рассмотрение контекста доступа и использования:
Если необходимо сделать check-out на продуктивной системе, следует управлять пользователями, имеющими доступ к системе, чтобы минимизировать риски. Использование сессий, ограниченных правами пользователя только на чтение, во время выполнения этих операций также может снизить вероятность утечки информации.
Выводы
В результате, добавление временного umask 077 действительно может помочь обеспечить дополнительную безопасность при выполнении операций check-out коммитов в Etckeeper. Однако, следует помнить о других аспектах безопасной работы с конфигурационными файлами и искать возможности для дополнительных ограничений, чтобы минимизировать риски раскрытия чувствительной информации. Рекомендуется также проводить такие операции в контролируемом окружении или в моменты, когда доступ к системе гораздо более ограничен.