sudoers: тонкая настройка прав и безопасность sudo

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

Как sudo принимает решение

При запуске sudo собирает набор правил из основного файла /etc/sudoers и подключённых файлов. Правила просматриваются сверху вниз, и последнее совпадение имеет приоритет. Поэтому запрет, поставленный выше разрешения, ничего не даст.

Основной файл подключает каталог /etc/sudoers.d через директиву @includedir. Локальные правила лучше хранить там: обновление пакета не перезапишет ваш файл, а отключить правило можно перемещением одного файла. Имена файлов не должны содержать точку или тильду — такие файлы игнорируются.

Безопасное редактирование

Никогда не редактируйте sudoers обычным редактором. visudo блокирует файл, проверяет синтаксис и не сохраняет заведомо сломанную версию. Для отдельного файла используется ключ -f, а ключ -c проверяет всё дерево без запуска.

sudo visudo
sudo visudo -f /etc/sudoers.d/admins
sudo visudo -c
sudo -l
sudo -l -U alice

Перед правкой откройте второй терминал и получите в нём root-сессию через su. Если правило окажется неверным, вы сможете исправить его, не перезагружаясь в recovery.

Базовая запись и алиасы

Формат правила состоит из четырёх частей: кто, на какой хост, от чьего имени и что может запускать. Хост обычно ALL, потому что файл и так локальный. Группы обозначаются знаком процента.

User_Alias ADMINS = alice, bob
Host_Alias LOCAL = 127.0.0.1
Cmnd_Alias WEB = /usr/bin/systemctl restart nginx, \
                 /usr/bin/systemctl reload nginx

ADMINS LOCAL = (root) WEB
%sudo ALL = (ALL:ALL) ALL

Алиасы нужны для читаемости, но не создают новых прав.

Ограничение команд

Разрешение на конкретные команды должно быть точным. Путь указывается абсолютный, аргументы — по возможности тоже. Строка с NOPASSWD удобна для автоматизации, но означает, что пароль не спросят вообще.

deploy ALL = (root) NOPASSWD: /usr/bin/systemctl restart myapp
backup ALL = (root) /usr/bin/rsync --archive /srv/data/ /backup/
alice ALL = (root) /usr/bin/systemctl status nginx, /usr/bin/journalctl -u nginx

Опасность в том, что многие программы умеют запускать другие команды. Редактор, find, awk, less, tar и даже systemctl с произвольным юнитом позволяют повысить привилегии. Если сервисный файл myapp.service доступен пользователю на запись, он может подменить ExecStart и получить root. Поэтому проверяйте не только команду, но и права на всё, что она читает.

Аргументы с пробелами и подстановками лучше не разрешать. Конструкция вида /usr/bin/systemctl restart * выглядит удобной, но звёздочка ищет совпадение по всей строке и может разрешить лишнее.

Теги и их побочные эффекты

Теги меняют поведение правила. NOPASSWD и PASSWD управляют запросом пароля. NOEXEC запрещает запуск дочерних процессов, но не спасает от встроенных команд интерпретатора. SETENV разрешает менять переменные окружения, что может обойти secure_path.

• NOPASSWD — только для узкой автоматизации, не для интерактивных команд.
• NOEXEC — дополнительная страховка, а не замена точному списку программ.
• SETENV — почти всегда лишний риск, оставляйте NOSETENV.
• LOG_INPUT и LOG_OUTPUT включают запись ввода и вывода: это полезно для аудита, но требует места.
• TIMEOUT — ограничение времени выполнения команды в секундах.

Параметры Defaults

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

Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Defaults timestamp_timeout=5
Defaults passwd_tries=3
Defaults lecture=always
Defaults logfile="/var/log/sudo.log"

env_reset очищает окружение, secure_path не даёт подменить системную команду своим бинарником, timestamp_timeout сокращает окно повторного ввода пароля. Значение 0 требует пароль каждый раз, отрицательное — не требует вовсе, что опасно.

sudoedit и работа от другого пользователя

Для правки файлов не нужно давать root-редактор. sudoedit копирует файл во временный каталог, открывает его от имени пользователя и затем проверяет, что файл не подменили, после чего записывает результат.

alice ALL = (root) sudoedit /etc/nginx/sites-available/, /etc/hosts
sudo -u postgres psql
sudo -u www-data -H /usr/bin/php /srv/app/script.php
sudo -k

Правило с sudoedit перечисляет пути, а не редактор. Переменные VISUAL и EDITOR могут быть ограничены через env_editor. Ключ -H меняет домашний каталог сервисного аккаунта. Команда sudo -k сбрасывает сохранённую метку времени, если нужно проверить, как работает запрос пароля.

Аудит и проверка

Проверяйте фактический результат: sudo -l -U показывает, что получит пользователь с учётом всех файлов. Для истории запусков используйте журнал systemd или auth.log, в зависимости от дистрибутива.

sudo -l -U alice
journalctl -t sudo --since today
journalctl _COMM=sudo --since "1 hour ago"
grep -i sudo /var/log/auth.log

В логах видно, кто запускал команду, от чьего имени и чем закончилось дело. Если включено I/O-логирование, появляются каталоги с расшифровкой сессий; доступ к ним должен быть только у root.

Типичные ошибки и восстановление

• Правило добавлено после запрещающего — запрет перекрыт.
• Файл в sudoers.d имеет точку в имени и молча игнорируется.
• Разрешён редактор или интерпретатор, что равно полному root.
• NOPASSWD выдан на команду, которая читает подконтрольный пользователю конфиг.
• Забыли проверить visudo -c и потеряли доступ после выхода из сессии.

Если sudo перестал работать, используйте активную root-сессию, вход через консоль или загрузку в recovery. В recovery корневая файловая система может быть только для чтения: перемонтируйте её, затем запустите visudo с полным путём. На некоторых системах выручает pkexec, если политика polkit разрешает административные действия.

Итог

Хороший sudoers — это короткий список точных разрешений, а не копия строки ALL для всех. Храните локальные правила в /etc/sudoers.d, проверяйте синтаксис через visudo и смотрите итог глазами пользователя через sudo -l -U. Не разрешайте редакторы и оболочки, не оставляйте NOPASSWD там, где достаточно пароля, и держите root-сессию открытой во время правки. Тогда тонкая настройка не превратится в потерю доступа.