Безопасная передача файлов на облачный Mac

Когда команда передаёт на облачный Mac материалы для подписи, тестовые данные или сборки, ожидающие приёмки, самая распространённая ошибка — сразу помещать их в корень репозитория. Как только файлы оказываются там, их могут немедленно обработать индексаторы, сценарии сборки и задачи очистки. Если архив содержит пути, выходящие за пределы целевого каталога, неверные права доступа или недокументированные расширенные атрибуты, проблема сразу распространяется на рабочую область. Надёжнее разделить «передачу» и «использование» на два отдельных этапа.

Сначала определите границы передачи

Для каждой передачи необходимо как минимум указать отправителя, получателя, назначение файлов и срок их хранения. Патчи исходного кода, тестовые фикстуры, артефакты сборки и учётные данные нельзя помещать в один архив. Учётные данные следует предоставлять через контролируемый механизм внедрения; они не должны попадать в переписку, журналы сборки или обычные пакеты с файлами.

Даже на выделенном физическом узле VMRunner для каждой задачи следует создавать отдельный временный каталог, а не повторно использовать постоянно существующий Downloads. В имени каталога можно указать номер заявки или внутренний идентификатор задачи, но не имя клиента, адрес электронной почты и другие конфиденциальные сведения.

umask 077
handoff_root="$HOME/Handoffs/task-4821"
install -d -m 700 "$handoff_root/incoming"
install -d -m 700 "$handoff_root/verified"
install -d -m 700 "$handoff_root/logs"
stat -f '%Su %Sg %Sp %N' "$handoff_root" "$handoff_root/incoming"

Команда umask 077 по умолчанию делает создаваемые впоследствии файлы доступными только текущему пользователю. install -d одновременно создаёт каталог и задаёт права, исключая короткий период открытого доступа между созданием каталога и последующей корректировкой разрешений.

Временная область предназначена не для постоянного хранения файлов, а для создания буферного слоя, в котором их можно проверить, отклонить или удалить до переноса в рабочую область проекта.

Перед отправкой создайте проверяемый манифест

Перед созданием контрольных сумм отправитель должен зафиксировать содержимое каталога. Не следует вычислять хеши, пока задача сборки продолжает изменять артефакты: в этом случае полученный адресатом манифест может относиться к другой версии файлов. Рекомендуется сначала скопировать материалы в каталог поставки с доступом только для чтения, проверить количество файлов и лишь затем создать манифест SHA-256.

Не включайте в пакет лишние данные

При передаче исходного кода исключите .git, локальные кеши, производные данные и файлы окружения. При передаче артефактов сборки, напротив, сохраните необходимую структуру подписи и расширенные атрибуты. Не перепаковывайте каталог приложения произвольным образом только ради уменьшения размера.

cd "$HOME/Delivery/task-4821"
find . -type f ! -name 'SHA256SUMS' -print0 \
  | sort -z \
  | xargs -0 shasum -a 256 > SHA256SUMS
shasum -a 256 SHA256SUMS

Получатель должен отдельно получить контрольную сумму самого файла SHA256SUMS через заранее подтверждённый внутренний канал. Если манифест и файлы передаются одним и тем же непроверенным способом, злоумышленник может подменить и то и другое.

Проверяйте файлы до распаковки

Сначала файлы должны поступать в incoming, а не перезаписывать содержимое репозитория. После завершения передачи зафиксируйте имена, размеры, владельцев и права доступа, а затем сравните контрольные суммы. При любом расхождении необходимо остановиться. Не пытайтесь «исправить и продолжить»: причиной отклонения может быть прерванная передача, повторная упаковка отправителем или подмена файла.

cd "$handoff_root/incoming"
shasum -a 256 -c SHA256SUMS
find . -maxdepth 2 -print0 \
  | xargs -0 stat -f '%z %Su %Sg %Sp %N' \
  > "$handoff_root/logs/received-files.txt"

Сначала проверьте пути внутри архива

Для ZIP-архива сначала выполните unzip -l package.zip, а для tar-архива — tar -tf package.tar. Отклоняйте пакеты, содержащие абсолютные пути, пути с ../, выходящие за пределы целевого каталога, или неожиданные символические ссылки. После проверки распаковывайте архив только в пустой каталог, а затем повторно проверяйте список файлов и права доступа.

Файлы macOS также могут содержать расширенные атрибуты. Используйте xattr -lr, чтобы просмотреть метки происхождения и другие атрибуты, и не удаляйте их рекурсивно по привычке. Обрабатывайте конкретный атрибут у конкретного файла только тогда, когда известно его происхождение, понятны последствия и этого действительно требует задача.

Ограничьте права при переносе в рабочую область

После успешной проверки скопируйте файлы в verified, откуда руководитель проекта сможет перенести их в рабочую область. Так сохранится принятая версия, отделённая от исходного содержимого передачи. Для обычных материалов можно оставить текущему пользователю права на чтение и запись; неизменяемые входные файлы, предназначенные только для чтения системой сборки, можно сделать доступными лишь для чтения.

cp -R "$handoff_root/incoming/ProjectInput" \
  "$handoff_root/verified/"
chmod -R go-rwx "$handoff_root/verified"
find "$handoff_root/verified" -type f -exec chmod 600 {} +
find "$handoff_root/verified" -type d -exec chmod 700 {} +

Не выполняйте рекурсивный chmod для всего проекта без разбора. Исполняемым сценариям, пакетам приложений и фреймворкам требуются разные права, а назначение режима 600 всем файлам может нарушить последующие задачи. Ограничивать права следует только у временной копии для текущей передачи. При окончательном импорте необходимые разрешения нужно восстановить в соответствии с данными репозитория или правилами сборки.

Если несколько человек работают через один облачный Mac, отдавайте предпочтение отдельным системным пользователям и отдельным каталогам. Временное предоставление глобального доступа на чтение и запись удобно, но не позволяет отследить происхождение файлов и ответственность за изменения.

По завершении убедитесь, что ничего не осталось

Перед завершением задачи убедитесь, что проект получил необходимые файлы, и запишите итоговую контрольную сумму. Затем проверьте наличие распакованных копий, пакетов от неудачных повторных попыток, вложений журналов и процессов, которые всё ещё держат файлы открытыми. Команда lsof +D может медленно работать с крупными каталогами, поэтому запускайте её только для временного каталога текущей передачи.

lsof +D "$handoff_root" 2>/dev/null
find "$handoff_root" -type f -maxdepth 4 -print
rm -rf "$handoff_root"
test ! -e "$handoff_root" && printf '%s\n' 'handoff removed'

Удаление временной области само по себе не завершает работу с секретами. Если конфиденциальное значение попадало в аргументы командной строки, историю Shell, журналы сборки или отчёты об ошибках, соответствующие записи необходимо очистить, а учётные данные — заменить. Для обычной передачи достаточно сохранить минимальный объём аудиторской информации: идентификатор задачи, время отправки и получения, контрольную сумму манифеста, результат приёмки и результат удаления. Содержимое файлов сохранять не следует.

Надёжный процесс удалённой совместной работы не должен зависеть от того, «помнят ли все об осторожности». Каждый файл обязан пройти четыре чётких этапа: изоляцию, проверку, авторизацию и удаление. После объединения этих команд в командные сценарии следует регулярно проверять на безопасных образцах обработку несовпадения хешей, путей с выходом за пределы каталога и некорректных прав, чтобы сценарии отказа были столь же работоспособны, как и штатный процесс.

Часто задаваемые вопросы