У меня есть GitLab Runner, и мои коллеги беспокоятся о таких командах, как
— Удалить элемент $ SOME_FOLDER * -Recurse -Force
может быть опасно. Например, если GitLab Runnier имеет права администратора, то случайный запуск этой команды может привести к плохим вещам ☢️:
— Remove-Item C: * -Recurse -Force
Чтобы исправить это, я создал местный сервисный аккаунт. Для целей этого вопроса мы можем предположить, что учетная запись была названа my_service_account. Я не назначал my_service_account никаким группам. Фактически, я даже не относил его к группе пользователей. Затем я дал my_service_account ПОЛНЫЙ КОНТРОЛЬ над каталогом развертывания.
К сожалению, пока my_service_account делает похоже, чтобы GitLab Runner не уничтожил всю хост-систему с помощью такой команды, как:
— Remove-Item C: * -Recurse -Force
оно делает не похоже, удерживает GitLab Runner от таких глупых вещей, как это:
— echo «test»> c: someExistingDir someNewGarbageFile.txt
Мой наставник и я немного изучили это, и мы обнаружили, что мы можем предотвратить создание случайных файлов GitLab Runner, применив отказываться от введите базовое разрешение FULL CONTROL для всех каталогов, которые мы хотим защитить. К сожалению, мы хотим защитить всю систему от этого и только разрешить GitLab Runner писать в каталог развертывания.
Поэтому я попробовал применить отказываться от введите базовое разрешение FULL CONTROL на всем диске C :, но когда я начал использовать для этого графический интерфейс MS Windows, мне показалось, что мне захотелось переопределить разрешения для нескольких Другой пользователи и группы, такие как администраторы, система, пользователи и аутентифицированные пользователи (см. рисунок):
Какой для меня самый простой и безопасный способ ОТКАЗАТЬ доступ к все системные файлы для my_service_account без использования упомянутого графического интерфейса, что может привести к «сопутствующему ущербу»?
ПРИМЕЧАНИЕ. Изображение графического интерфейса фактически получено с моего домашнего ПК и не машина, на которой размещен GitLab Runner. Изображение предоставлено, чтобы проиллюстрировать проблему, когда графический интерфейс требует, чтобы я изменил разрешения для пользователей и групп, которые находятся вне сферы действия IMO.
1 ответ
Какой для меня самый простой и безопасный способ ЗАПРЕТИТЬ доступ ко всем системным файлам …
Вы хотите убедиться, что учетная запись пользователя, в которой работает служба, или контекст, в котором могут запускаться команды, не имеют прав локального администратора в системе.
Я не хочу изменять права доступа к вложенным папкам для этих пользователей …
Когда вы устанавливаете новую NTFS «deny«править в»C:« уровень, вы не можете защитить какие-либо дочерние файлы и папки, если вы не «Replace all child object permission entries with inheritable permission entries~«от родительского объекта, для которого вы устанавливаете новое правило запрета.
То, что вы устанавливаете на родительском уровне, необходимо унаследовать и распространить на все дочерние объекты, чтобы эти ограничения разрешений стали эффективными и для дочерних объектов.
Также обратите внимание, что даже проверка этого параметра и разрешение любых новых ограничительных разрешений NTFS распространяться на дочерний объект не повлияет на папки или файлы, наследование которых явно не установлено или нарушено.
Чтобы все было просто, Я бы удостоверился, что учетная запись службы не имеет доступа локального администратора к системе, имеет хорошие резервные копии системы и процессы восстановления / восстановления, а также проверяет выполняемые команды, чтобы попытаться сломать ее.