sudo – делегируем полномочия

Задача sudo , дать обычному пользователю в Linux возможность выполнения команд от имени root или другого пользователя. Помимо этого ведется лог всех выполненных команд и аудит безопасности – неудачных доступов. Все выгоды использования sudo очевидны. Если пользователю необходимо выполнять некие задачи, для которых требуется root-доступ, нет необходимости давать ему пароль от суперпользователя. Можно просто задать доступ именно к необходимым функциям. При этом все его действия будут писаться в лог-файл и в случае необходимости можно всегда провести аудит.

Установка

В 90% случаев пакет уже установлен, но бывают редкие исключения. Но это легко исправить, установка не отличается от установки любого другого ПО.

Установка sudo в CentOS/RedHat и т.п.

с менеджером yum

с dnf

Установка sudo в Debian/Ubuntu и т.д.

Вводная информация

Для начала давайте создадим пользователей над которым будем ставить эксперименты (подробно про создание пользователей можно почитать тут – Пользователи в Linux — добавление, изменение, удаление):

Сразу поместим нашего пользователя hc в группу wheel. Традиционно, в эту группу помещаются пользователи, которые будут иметь административный доступ. Это повелось еще с тех пор, когда основным инструментом для делегирования прав была команда su . Если интересуют подробности – поищите сами.

Второй пользователь нужен нам для разнообразия.

Файл конфигурации /etc/sudoers и visudo

Все настройки хранятся в файле /etc/sudoers . Файл этот не совсем обычный, даже под рутом просто так его отредактировать не получиться, т.к. запись в файл запрещена. Для работы с этим файлом есть специальная утилита visudo . Смысл такого ограничения вот в чем. Любая ошибка делает sudo неработоспособным, стоит ошибиться или описаться и получаете кучу проблем. Вы можете совсем лишиться доступа к административным функциям и придется пользоваться recovery mode для восстановления доступа. Это если у вас есть физический доступ к серверу. А если это VPS?

Что бы такое не происходило visudo при запуске блокирует файл sudoers и для редактирования открывает копию. При сохранении происходит проверка синтаксиса и если допущена ошибка – выдаст об этом предупреждение.

В ответ введите:
e – откроет снова файл для исправления ошибки;
x – не сохранять изменения;
Q – сохранит файл не смотря на ошибки (так лучше не делать);

ВАЖНО! В некоторых “инструкция” которые можно найти предлагают делать следующее – сначала root разрешает запись в файл sudoers , что то типа:

потом просто редактируем файл и снимаем запись chmod -w . Ни когда так не делайте!
Чаше всего так советуют из нежелания пользоваться редактором vi, который запускается по умолчанию через visudo . Если вам не нравиться vi , его можно спокойно заменить на любой другой. Для этого в консоли выполните, например:

В этом случае запуститься редактор nano вместо vi.

Меняем редактор visudo

Если же хотите, назначить редактор на постоянную основу, переопределите значение EDITOR. Я обычно это делаю через пользовательский конфиг оболочки – для bash это ~/.bashrc . Добавьте в файл следующую строку:

Зайдите в сессию заново, выполните для проверки:

Если не хотите менять системный редактор, а задать только для visudo, добавьте в sudoers след. строки:

Использование

Давайте теперь рассмотрим использование sudo на конкретных примерах.

Активируем запись log-файла для sudo

Добавляем в конфигурационный файл след. строку:

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

Разрешим пользователям группы wheel полный административный доступ.

Откройте конфигурационный файл и найдите строку:

уберите символ # , чтобы раскомментировать строку и сохраните файл. Если вдруг такой строки вы не нашли, то просто добавьте ее.

Для проверки зайдите на сервер пользователем hc и выполните sudo -s :

Введя еще раз пароль от пользователя hc вы получите доступ к консоли с правами root.

Для сравнения залогиньтесь как user1 – получите что-то похожее:

Посмотрим log-файл /var/log/sudo.log , увидим информацию, что user1 пытался использовать sudo, не имея на это прав:

Убираем запрос пароля при запуске команд через sudo

Для той же группы wheel:

А ТЕПЕРЬ ВНИМАНИЕ! Ни когда не даем пользователю полного доступа, как в предыдущем примере и тем более, без ввода пароля, как описано в этом! Всегда давайте ровно столько, сколько надо!

Примеры безопасного делегирования прав

Разрешим user1 пользоваться yum (для Debian/Ubuntu заменить yum на apt-get), добавим строчку:

Теперь user1 может выполнить:

и установить ту программу которая ему нужна.
Если же выполнить без добавления sudo:

Создадим группу yumusers и добавим туда user1:

Изменим строчку в sudores следующим образом:

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

Формат записей выделения прав

Давайте поподробнее разберем, что же значат все эти ALL. Структура строки следующая:

Т.е. запись:

означает – пользователь user1, на любом хосте, может от имени root запустить yum и mount, т.е. установить программу или примонтировать раздел.

Алиасы в sudo

В реальности, вряд ли вы ограничитесь только одной командой для одного пользователя. Скорее всего вам будет нужно выдать целый список доступов. Можно конечно каждый раз перечислять все через запятую, а можно и задать алиас. Что он из себя представляет:

и теперь вы можете написать:

В sudoers уже созданы несколько алиасов на наиболее распространенные группы команд, их достаточно раскомментировать и можно использовать.