Файл sudoers в Linux — руководство по безопасному редактирования

Файл sudoers (/etc/sudoers) контролирует, кто и как может запускать команды с правами суперпользователя. Никогда не редактируйте файл напрямую — используйте visudo. Правила позволяют ограничивать команды, менять таймауты, включать NOPASSWD и усиливать безопасность через use_pty. В статье — примеры правил, чек-листы, план отката и рекомендации по тестированию.

Оглавление

• Что такое файл sudoers?
• Когда нужно менять sudoers?
• Как безопасно редактировать sudoers?
• Какие параметры можно менять в sudoers?
  • Изменение таймаута
  • Ограничение команд и прав
  • Группы и % как префикс
  • Усиление через use_pty
  • Запуск sudo без пароля
  • Смена редактора visudo
• Практические примеры и антипаттерны
• Методики тестирования и критерии приёмки
• План отката и аварийный сценарий
• Чек-листы по ролям
• Модель принятия решений
• Часто задаваемые вопросы
• Краткое резюме

Что такое файл sudoers?

Файл sudoers — это текстовый конфигурационный файл, расположенный в каталоге /etc и управляющий поведением sudo. Он определяет:

• какие пользователи и группы могут выполнять команды с повышенными правами;
• от имени каких учётных записей они могут выполнять команды;
• какие конкретно команды разрешены или запрещены;
• глобальные опции для sudo (таймауты, поведение pty, письма и т.д.).

Файл используется демоном sudo при проверке прав. Неправильная правка может привести к потере возможности пользоваться sudo и к блокировке администрирования системы.

Когда нужно менять sudoers?

Вы редактируете sudoers, когда:

• нужно дать новому пользователю возможность выполнять административные команды;
• необходимо выдать тонкие, ограниченные привилегии для конкретных задач (например, обслуживание веб-сервера);
• требуется изменить глобальное поведение sudo (таймаут, отправку писем, sandbox);
• вы автоматизируете задачи и хотите использовать NOPASSWD для конкретных команд в строго контролируемых условиях.

Важно: операции с sudoers всегда должны сопровождаться тестами и планом отката. Редактирование на продакшене без тестирования — риск.

Как безопасно редактировать sudoers?

Никогда не открывайте /etc/sudoers обычным текстовым редактором. Всегда используйте утилиту visudo, она выполняет проверку синтаксиса и блокирует файл от одновременного редактирования:

sudo visudo

visudo по умолчанию откроет файл в системном редакторе (обычно nano или vi/vim). Если синтаксис неверный, visudo предупредит и не сохранит испорченный файл.

Примечание: можно редактировать включаемые конфигурационные фрагменты (например /etc/sudoers.d) — это удобный способ хранить правила по ролям и системам управления конфигурацией.

Какие параметры можно менять в sudoers?

Ниже перечислены часто используемые возможности с примерами и объяснениями.

Изменение таймаута

Поведение по умолчанию: после ввода пароля при использовании sudo вы получаете короткий период «льготного времени», когда повторное использование sudo не требует повторного ввода пароля. Это можно изменить через опцию Defaults timestamp_timeout.

1. Откройте visudo: sudo visudo.
2. Перейдите в конец файла и добавьте строку, например:

Defaults timestamp_timeout=0

Значение в секундах определяет длительность льготного периода. 0 означает, что при каждом запуске sudo потребуется пароль; значение -1 отключает истечение льготного периода и даёт бесконечную сессию — не рекомендуется.

1. Сохраните изменения и выйдите (Ctrl+O, Ctrl+X в nano; :wq в vim).

Важно: уменьшение таймаута повышает безопасность, но может ухудшить удобство операций при администрировании.

Ограничение, кто и какие команды может запускать

Строка правила имеет формат:

username hostlist = (userlist) commandlist

• username — целевой пользователь в системе, для которого действует правило;
• hostlist — список хостов, где правило применимо; обычно LOCALHOST;
• userlist — список учётных записей, от имени которых можно выполнять команды;
• commandlist — перечень допустимых команд.

Пример полного привилегирования (небезопасно для большинства случаев):

ramces ALL=(ALL) ALL

Пример более ограниченного правила, где ramces может выполнять команды только как root:

ramces ALL=(root) ALL

Пример разрешения только одной команды apt update:

ramces ALL=(root)/usr/bin/apt update

Если поставить % перед именем, это обозначает группу, например %admin ALL=(root) ALL даёт всем членам группы admin root-права.

Антипаттерн: правило ALL=(ALL) ALL даёт практически неограниченные права и должно использоваться только там, где это оправдано и документировано.

Усиление sudo через use_pty

Чтобы запускать команды через защищённый псевдотерминал, можно включить:

Defaults use_pty

Это помогает минимизировать риск перехвата ввода/вывода команд на скомпрометированном терминале.

Запуск sudo без пароля

Для автоматизации иногда удобно разрешить запуск определённых команд без запроса пароля:

ramces ALL = (root) NOPASSWD: /usr/bin/systemctl status nginx

Используйте NOPASSWD очень экономно и указывайте только те команды, которые безопасно исполнять без пароля.

Смена редактора visudo

Чтобы visudo открывал нужный вам редактор, на Ubuntu используйте:

sudo update-alternatives --config editor

На других дистрибутивах можно установить переменную окружения в ~/.bashrc:

export EDITOR="vim"

После этого visudo будет использовать выбранный редактор.

Практические примеры и антипаттерны

1. Правило для обслуживания веб-сервера (без полного root-доступа):

wwwadmin ALL=(www-data) /usr/bin/systemctl restart nginx, /usr/bin/journalctl -u nginx

Это позволяет пользователю wwwadmin выполнять только рестарт и просмотр логов для nginx от имени www-data.

2. Неправильное использование шаблонов и подстановок — избегайте широких wildcard, например /var/*, если есть риск подстановки пробелов или специальных символов.

3. Не давайте NOPASSWD для команд, которые позволяют выполнить оболочку (например, запуска скрипта с передачей аргументов, которые изменяют PATH).

Методики тестирования и критерии приёмки

Критерии приёмки перед роллаутом изменений в sudoers:

• visudo проходит проверку синтаксиса без ошибок;
• тестовый пользователь выполняет именно те команды, которые разрешены, и не может выполнить запрещённые;
• автоматические сценарии (CI/Ansible/chef/puppet) продолжают работать с новыми правилами;
• журнал sudo (обычно /var/log/auth.log или systemd journal) показывает ожидаемую запись о вызовах команды;
• резервная копия прежнего файла доступна и задокументирована.

Минимальные тесты (пример):

• проверка чтения файла: sudo -l -U alice показывает список доступных команд;
• попытка запуска запрещённой команды возвращает ошибку;
• проверка NOPASSWD работает только для указанных команд.

План отката и аварийный сценарий

Если после правки sudoers вы потеряли доступ к sudo, используйте один из методов восстановления:

1. Переключитесь на root с помощью su (если известен пароль root).
2. Если root не доступен, загрузитесь в single-user mode или recovery mode через загрузчик (GRUB) и отредактируйте /etc/sudoers или добавьте правильный файл в /etc/sudoers.d.
3. Если система полностью недоступна, загрузитесь с live-USB, смонтируйте корневой раздел и восстановите /etc/sudoers из резервной копии.

Шаги отката (короткий SOP):

• Если есть доступ к root: откройте /etc/sudoers.d/restore_sudoers и восстановите рабочую версию, затем visudo -c для проверки синтаксиса.
• Если нет доступа: загрузка в Rescue → правка /etc/sudoers → chmod 0440 /etc/sudoers → exit и перезагрузка.

Критерии успешного отката: sudo возвращён к рабочему состоянию, и доступ администратора восстановлен.

Чек-листы по ролям

Администратор (on-call)

• Проверить текущие правила: sudo -l -U .
• Сделать резервную копию: sudo cp /etc/sudoers /etc/sudoers.bak.$(date +%F_%T).
• Применить изменения через visudo.
• Выполнить smoke-тесты для ключевых пользователей.
• Зарегистрировать изменение в системе управления изменениями.

DevOps / CI

• Убедиться, что сервисы, зависящие от sudo, документированы.
• Добавить автоматические тесты для сценариев с sudo.
• Использовать /etc/sudoers.d для конфигураций, управляемых автоматически.

Десктоп-пользователь

• Запросить минимально необходимые права.
• Не запрашивать NOPASSWD без обоснования.
• Документировать каждую просьбу на изменение прав.

Модель принятия решений

Ниже представлен упрощённый поток решений в формате диаграммы (Mermaid). Используйте её как чек-лист перед изменением sudoers.

flowchart TD
  A[Требуется административная команда?] -->|Нет| B[Ничего не менять]
  A -->|Да| C[Нужна ли автоматизация без пароля?]
  C -->|Да| D[Ограничить NOPASSWD точными командами]
  C -->|Нет| E[Дать минимальный доступ через 'root' и commandlist]
  D --> F[Добавить запись в /etc/sudoers.d и протестировать]
  E --> F
  F --> G[Провести тесты и доки]
  G --> H[Деплой в staging]
  H --> I{Все тесты пройдены?}
  I -->|Да| J[Деплой в prod с мониторингом]
  I -->|Нет| K[Откат и анализ]

Риски и смягчающие меры

Совместимость и миграция

• На Ubuntu и Debian visudo работает одинаково; путь /etc/sudoers и /etc/sudoers.d поддерживаются.
• На некоторых встраиваемых системах может отсутствовать /etc/sudoers.d — используйте основной файл, но осторожно.
• Если управляете множеством хостов, храните фрагменты в /etc/sudoers.d/ и применяйте через инструмент управления конфигурацией (Ansible/Chef/Puppet).

Полезная сводка команд и сниппетов

Проверка текущих привилегий пользователя:

sudo -l -U alice

Проверка синтаксиса sudoers без сохранения (visudo делает это автоматически):

visudo -c

Создание файла в /etc/sudoers.d:

echo 'deploy ALL=(www-data) NOPASSWD: /usr/bin/systemctl restart myapp' | sudo tee /etc/sudoers.d/deploy
sudo chmod 0440 /etc/sudoers.d/deploy

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

1. Появилась ошибка “(username) is not in the sudoers file”. Сломан ли sudo?

Нет. Это означает, что текущая учётная запись не имеет записи в sudoers и не входит в группу, которой предоставлены привилегии. Чтобы исправить:

• Войдите как root (su) или загрузитесь в режим восстановления;
• Откройте visudo и добавьте правило, например:

alice ALL=(root) ALL

• Сохраните и проверьте работу sudo под пользователем alice.

2. Какие проблемы возникают при создании пользовательских правил?

Частая ошибка — использование шаблонов и wildcard’ов без должной проверки. Подстановочный символ * может неожиданно подставлять пробелы или символы, что расширит разрешения. Лучше указывать полные пути к программам и минимально необходимые аргументы.

3. Можно ли запретить отправку почты при запуске sudo?

Да. Используйте метку NOMAIL в правиле. Пример:

ramces ALL=(root) NOMAIL: ALL

Это запрещает отправку почтовых уведомлений sudo по почтовой подсистеме системы.

Сводка ключевых рекомендаций

• Всегда используйте visudo для изменений.
• Делайте резервные копии перед правками.
• Минимизируйте права: давайте только необходимые команды.
• Избегайте NOPASSWD и wildcard’ов без строгого обоснования.
• Храните автоматизируемые правила в /etc/sudoers.d и управляйте ими через конфигурационные инструменты.
• Иметь план восстановления и протестировать его заранее.

Короткая подсказка на будущее: документируйте каждое изменение sudoers в системе управления изменениями и привязывайте правило к определённому инциденту или задаче.

Image credit: a hero with computer circuit by 123RF

Краткое резюме

Файл sudoers — критический компонент безопасности в Linux. Правильное управление правилами, минимизация привилегий, тестирование и наличие плана отката значительно снижают риск простоя и компрометации. Используйте visudo, фрагментацию через /etc/sudoers.d и осторожно применяйте NOPASSWD.