Архитектура привилегий sudo

от

“sudo воспринимают как волшебную команду, но это архитектурный механизм управления привилегиями. Его сила и уязвимость лежат в неочевидных деталях конфигурации, которые проверяют в рамках требований ФСТЭК. Без аудита sudoers безопасность превращается в формальность.”

sudo: архитектура привилегий, а не «волшебная команда»

Как работает механизм повышения привилегий в Linux: от бита setuid до аудита по требованиям ФСТЭК.

Название расшифровывается буквально: superuser do. Ключевой архитектурный выбор: вместо постоянной сессии root — временное повышение прав для конкретной команды. Это реализовано через несколько взаимосвязанных механизмов.

Базовый механизм: setuid, PAM и парсер правил

При вызове sudo происходит цепочка событий:

  • Setuid-бит. Исполняемый файл /usr/bin/sudo имеет права 4755. Процесс запускается с правами владельца (root), но первоначальный вызов происходит от имени обычного пользователя.
  • PAM-стек. Модуль /etc/pam.d/sudo выполняет аутентификацию, запрашивая пароль текущего пользователя, а не пароль root.
  • Парсинг правил. Движок sudo последовательно проверяет файлы /etc/sudoers и /etc/sudoers.d/*. Первое совпавшее правило применяется.

Если проверки проходят, процесс порождает дочерний процесс с повышенными правами root для выполнения команды, после чего права сбрасываются.

Конфигурация sudoers: логика парсинга и скрытые риски

Файл /etc/sudoers парсится сверху вниз. Первое совпавшее правило применяется — последующие игнорируются. Это приводит к типичной ошибке, когда общее правило блокирует специфическое.

# НЕПРАВИЛЬНО: правило для backup_user перекрывается общим запретом
backup_user ALL=(ALL) NOPASSWD: /usr/bin/rsync
%developers ALL=(ALL) ALL

# ПРАВИЛЬНО: специфичные правила размещают ДО общих
backup_user ALL=(ALL) NOPASSWD: /usr/bin/rsync
%developers ALL=(ALL) ALL

Одна из самых критичных ошибок — разрешение запуска интерпретаторов командной оболочки:

# КРИТИЧЕСКАЯ ОШИБКА: разрешение shell-интерпретатора
deploy_user ALL=(ALL) NOPASSWD: /bin/bash
# После этого: $ sudo /bin/bash → получаем полный root без пароля

Для безопасного редактирования используют только утилиту visudo. Она проверяет синтаксис перед сохранением и блокирует одновременное редактирование. Прямое редактирование через текстовый редактор может оставить систему без работающего механизма sudo при синтаксической ошибке.

Требования ФСТЭК и организация аудита

Согласно требованиям ФСТЭК (п. 40 Приказа №31) и ГОСТ Р 57580.2-2017, действия с повышенными привилегиями должны регистрироваться с привязкой к конкретному пользователю.

Стандартные системные журналы

По умолчанию sudo логирует события в системные журналы аутентификации: /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (RHEL/CentOS). Формат записи позволяет отследить детали:

Feb 8 14:23:01 srv01 sudo: ivanov : TTY=pts/2 ; PWD=/home/ivanov ; USER=root ; COMMAND=/bin/systemctl restart nginx

Для выбора только событий выполнения команд, исключая записи об открытии/закрытии сессии, используют фильтрацию.

Расширенное логирование в отдельный файл

В /etc/sudoers можно добавить директивы для детального аудита:

Defaults logfile="/var/log/sudo.log"
Defaults!sudo log_input, log_output
Defaults mail_badpass

Эти настройки включают:

  • Запись всех событий sudo в отдельный файл.
  • Запись ввода и вывода выполняемых команд (требует установки дополнительного пакета).
  • Отправку уведомления администратору при вводе неверного пароля.

Для соответствия требованиям к защите персональных данных (ФЗ-152) журналы должны храниться не менее установленного срока и быть защищены от несанкционированного изменения, например, через установку атрибута «только добавление».

Практический аудит: ключевые проверки

Регулярный аудит конфигурации sudo позволяет оценить соответствие принципу минимальных привилегий.

1. Обнаружение избыточных прав

Проверка наличия правил, дающих пользователям неограниченный доступ:

grep -E '^[^#]*s+ALL=(ALL)s+ALL' /etc/sudoers /etc/sudoers.d/* 2>/dev/null

Целевой показатель для обычных пользователей — отсутствие таких записей.

2. Выявление правил без парольной аутентификации

Поиск директив NOPASSWD:

grep NOPASSWD /etc/sudoers /etc/sudoers.d/* 2>/dev/null

Такие правила допустимы только для автоматизированных системных задач с чётко ограниченным списком команд.

3. Анализ истории использования привилегий

Для детальной трассировки используют систему аудита auditd:

ausearch -m USER_CMD -ts today | grep -E 'exe=.*sudo'

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

Результаты этих проверок интегрируют в регулярные процедуры аудита безопасности. Отклонения от целевых показателей становятся триггером для расследования.

Итог: sudo как политика безопасности

Эффективность sudo определяется не его технической реализацией, а дисциплиной управления конфигурационными файлами. Одно разрешённое правило для /bin/bash делает бессмысленным весь периметр защиты, построенный на принципе минимальных привилегий. Аудит начинается не с поиска уязвимостей в ядре, а с проверки соответствия файла sudoers реальным потребностям и регламентам.

Готовы проверить свои правила sudoers на соответствие требованиям регуляторов?

Интеграция проверок в процесс аудита безопасности, настройка SIEM для мониторинга событий повышения привилегий и формирование корректной конфигурации под требования ГОСТ — часть системного подхода к защите инфраструктуры.

Загрузка…

Оставьте комментарий