У меня есть эволюция Предыдущий вопрос.
Главный вопрос: каковы значимые различия между запуском программы от имени пользователя root и через учетную запись службы с записью файла sudoers?
Мне нужно развернуть сторонний программный агент в среде RHEL моего клиента, заботящегося о безопасности. В результате установки по умолчанию файлы и папки агента принадлежат пользователю root, и он запланирован для запуска при запуске, завершении работы или через файл crontab; но в любом случае он работает как корневой процесс, что никому из службы безопасности, похоже, не нравится.
Поставщик предположил, что более безопасной альтернативой является выполнение агента через учетную запись службы с записью файла sudoers: например:
agent-user ALL=NOPASSWD: /opt/agent/agent-executable
Но действительно ли это лучше с точки зрения безопасности? Или что лучше всего в этой ситуации?
На мой взгляд, в любом случае агент получит привилегированный доступ к серверу. А учетная запись службы - это настройка, которая (хотя и поддерживается поставщиком) кажется возможностью делать ошибки.
Является NOPASSWD: уязвимостью безопасности, и будет предусматривать оболочку /sbin/nologin повысить безопасность?
Каковы значимые различия между запуском программы от имени пользователя root и учетной записью службы via с записью файла sudoers?
Но действительно ли это лучше с точки зрения безопасности? Или что лучше всего в этой ситуации?
Конечный результат действительно тот же: /opt/agent/agent-executable работает с привилегиями root со всеми рисками, связанными с этим уровнем привилегий.
«Лучшая практика - это просто еще одно мнение».
IMHO вариант sudo - это то, что я бы порекомендовал, когда служба состоит из основного процесса и (многих) компонентов, которым для правильной работы не требуются привилегии root и которые с радостью будут работать при использовании agent-user идентичности, но есть некоторые специфические, легко идентифицируемые компоненты (например, agent-executable) действительно нужен такой root-доступ.
Для этого требуется, чтобы администратор предоставил, а основная служба поддерживала возможность запускать эти конкретные компоненты в измененном контексте с повышенными привилегиями. sudo особенно подходит для этого (и гораздо лучший вариант, чем, например, установка бита SUID в исполняемом файле).
Тогда вы соблюдаете безопасность принцип наименьших привилегий.
Когда вы, например, создаете модуль systemd, такой как этот:
[Service]
User=agent-user
ExecStart=sudo /opt/agent/agent-executable
который инструктирует systemd (который запускается как root) переключиться на идентификатор пользователя-агента для запуска службы в среде с ограниченными привилегиями. Затем, как ограниченный пользователь, вы используете sudo чтобы снова повысить привилегии для запуска службы от имени пользователя root.
В этом сценарии вы просто ведете себя глупо и с таким же успехом можете запустить исполняемый агент с правами root с самого начала и сделать следующее:
[Service]
# User=root
ExecStart=/opt/agent/agent-executable
Примечание: есть некоторые тонкие различия в результирующей среде, когда вы запускаете процессы через sudo или systemd (с и без явный User=root), которые, вероятно, не актуальны в данный момент.
Является ли NOPASSWD слабым местом безопасности?
В случае услуг и автоматизации часто неизбежны.
Улучшит ли безопасность использование оболочки / sbin / nologin?
В общем: не так много, как думают. См. Например этот вопрос и ответ.