Вкратце, sudo позволяет запускать какие-то команды от имени какого-то пользователя. А в файле sudoers пишутся те самые политики – кому, где и что. Из того, что мы уже видели – наш пользователь может запускать команды от имени суперпользователя. Давайте для начала найдём, где это написано.
Спускаемся вниз, где у нас начинаются политики. Например, root ALL=(ALL) ALL. Первое – это пользователь, для которого написана политика. Если начинается со знака процент, то речь о группе пользователей. Не то, чтобы руту были нужны sudo права – он и так может делать всё что угодно. Но без этой строчки если рут почему-то запустит sudo, допустим, если это написано в скрипте, или кто-то скопировал команды с интернета и всё такое – то sudo выдаст ошибку и команда не сработает. Поэтому, на всякий случай, есть эта строчка.
Теперь, что означает ALL ALL ALL. Первая ALL, перед знаком равно, это на каком компьютере. Если первое значение - ALL или совпадает с именем компьютера, которое можно узнать с помощью команды hostname, то sudo будет работать с этой строчкой. Если же тут написано что-то другое – то sudo проигнорирует эту строчку. Если у вас несколько компьютеров, вы можете написать один файл sudoers и закинуть его на все машинки. И sudo везде будет считывать только строчку, где хост равен ALL или совпадает с хостнеймом машинки.
Вторая ALL – от имени какого пользователя, ALL значит от всех, то есть можно запустить команду от имени любого пользователя. По умолчанию, если явно не указывать пользователя, то команда запустится от имени root. А так, здесь можно написать конкретного пользователя, допустим user2. В таком случае пользователь root сможет запускать команды с помощью sudo только от имени user2. Также тут можно указать не только пользователя, а также группу, или просто группу. Чуть дальше будут примеры.
И третья ALL – это команды. В случае ALL можно запустить любую команду, а так, здесь можно прописать только те команды, которые вы хотите разрешить. Или наоборот, если вы хотите какие-то команды разрешить и какие-то запретить. Перед запрещёнными командами ставится восклицательный знак.
Так вот, почему наш пользователь user может запускать команды с помощью sudo? Пока что в этом файле всего 2 политики – для пользователя root и для группы wheel, всё остальное – закомментированные примеры. У группы wheel тоже все права – ALL ALL ALL. Чтобы узнать, в каких группах состоит наш пользователь, можно выполнить команду groups от его имени, либо указать имя пользователя (groups, groups user, groups user2). Как видно, наш пользователь user состоит в группе wheel – именно поэтому у него есть все права на систему. В других дистрибутивах вместо wheel может быть группа c именем sudo – но суть одна и та же.
Прежде чем пойдём дальше, давайте я покажу частный случай использования sudo – sudo su. Если выполнить просто команду su, то мы меняем текущего пользователя на root пользователя, правда для этого нам нужно знать пароль этого рут пользователя. Команда sudo позволяет нам выполнить команду от имени суперпользователя, а мы знаем, что если выполнять команду su от имени root пользователя, то пароль нам указывать не нужно. А значит выполнив sudo su и введя пароль своего юзера, мы просто от имени суперпользователя запустим команду su, а так как ему не нужно вводить пароль, мы просто станем рутом. Таким образом, не зная пароля рута, мы можем стать рут пользователем.
Учитывая, что sudo – это механизм, который позволяет повысить свои привелегии, этим активно пользуются злоумышленники. Давайте, для примера, посмотрим один из теоретических способов с помощью переменной PATH. У меня в переменной (echo $PATH) есть путь /home/user/.local/bin. Сейчас этой директории нет, но я могу её создать (mkdir ~/.local/bin) и сделать такую обманку – создать символическую ссылку ln -s /bin/su ~/.local/bin/htop. Теперь когда я пишу htop, bash смотрит переменную PATH, видит в начале ~/.local/bin, находит там программу htop и запускает, а на самом деле это программа su. И представьте ситуацию, если мы разрешим пользователю запускать только команду htop c правами суперпользователя, допустим чтобы понижать niceness, а этот пользователь напишет sudo htop – на деле выполнится sudo su – и он введя свой пароль станет рут пользователем.
Естественно этой очень банальный способ и его невозможно применить – во первых, sudo требует, чтобы в sudoers был полный путь к программам, то есть если в sudo явно не указан путь /home/user/~.local/bin/htop – то ничего не сработает, во вторых – в sudoers есть настройка secure_path. Когда пользователь будет писать sudo и команду, то sudo будет смотреть только в директории, указанные в этой настройке. Кстати, насчёт полного пути – его всегда можно легко найти с помощью команды which – допустим, which htop, which ls, which rm.
Но нужно понимать, что при ALL ALL ALL у пользователя будет полный доступ, а если вы ограничиваете пользователя определёнными командами, нужно быть предельно осторожным с выбором команд, потому что очень часто можно повысить привилегии неочевидным способом. Допустим, давая кому-то право создавать пользователей, он может создать пользователя с группой wheel, и через него стать рутом. Поэтому, прежде чем давать какому-то пользователю права на какую-то программу, следует очень внимательно изучить, что эта программа позволяет сделать. Допустим, тот же less или vi позволяют запускать команды – и для них есть специальный ключ, позволяющий предотвратить выполнение сторонних команд NOEXEC. Кроме NOEXEC есть еще пара ключей, один из примечательных - NOPASSWD – позволяет запускать указанные команды без ввода пароля. Также, чтобы постоянно не вводить sudo, можно предварительно написать sudo -s.
Также в некоторых случаях люди используют sudo чтобы предоставить доступ к редактированию каких-то файлов. И хотя лучше в таких случаях использовать права на файлы, ситуации бывают разные, поэтому у sudo есть относительно безопасный способ редактирования файлов с помощью sudoedit. Для примера, давайте предоставлю пользователю user2 право редактировать файл /etc/passwd с помощью nano. Он вроде бы и не может открыть командой другой файл, но я могу изнутри nano открыть другой файл, допустим, тот же sudoers, изменить его, и сохранить как /etc/sudoers, тем самым обеспечив себе все права. Если же в sudoers я пропишу sudoedit, то предыдущая схема не будет работать, потому что принцип работы немного другой – sudoedit копирует нужный мне файл во временный файл, я редактирую временный файл, а когда сохраняю – то sudoedit заменяет нужный файл той копией, которую я изменил.
Когда у вас много пользователей, много разных команд и компьютеров, для облегчения прописывания политик можно использовать алиасы, где можно перечислить несколько значений через запятую. В файле уже даны примеры использования. Политика состоит из 4 столбиков: User – это собственно пользователь или группа, к которой применяется политика, поэтому алиас называется User_Alias. Во втором столбике хостнеймы, поэтому Host_Alias. Дальше у нас столбик, где указывается от чьего имени разрешено запускать – называется Runas – собственно, Runas_Alias и последний столбик – команды, поэтому здесь Cmnd_Alias. Ну и тут пример использования политик с алиасами.
Также бывает полезно узнать, кто какие команды вводил с помощью sudo. Все действия sudo логирует и их можно посмотреть в файле /var/log/secure (sudo grep sudo /var/log/secure ). Также в плане логирования, у sudo есть инструмент, называемый sudoreplay. Я его разбирать не буду, это вам такое задание – настроить и проверить его работу. Если будут какие-то сложности – спрашивайте в комментариях.
Последняя строчка файла говорит нам, что sudoers будет читать настройки из всех файлов, расположенных внутри директории /etc/sudoers.d . Для этого нам понадобится указать для visudo файл – sudo visudo -f /etc/sudoers.d/test . И здесь, давайте пропишем, допустим, пользователь user2 может запускать на этой машине от имени рута команду passwd, тем самым он сможет менять пароли другим пользователям, но чтобы он не мог поменять пароль руту, мы пропишем запрет - passwd root (user2 centos8=(root) /usr/bin/passwd, !/usr/bin/passwd root ). Ну и еще правило от пользователя, допустим, чтобы user2 мог от имени пользователя user запускать команду ls (user2 centos8=(user) /bin/ls . Сохраним и проверим – su user2, sudo passwd user, sudo passwd root. ls /home/user/, sudo – u user ls /home/user
Подводя итоги – sudo – инструмент, который позволяет дать определённым пользователям определённые права. Но это делает sudo очень опасным инструментом, которым активно пользуются злоумышленники. Поэтому нужно запомнить – без острой необходимости пользователей в sudo прописывать не стоит, если речь идёт о правах суперпользователя. Не стоит строить правила на основе запретов – разрешить всё, а потом запретить опасные команды. Это заведомо проигрышный вариант – есть огромное количество способов обойти запреты. Давайте доступ только на необходимые команды, заранее проанализируйте, посмотрите в интернете, а насколько опасно то, что вы разрешаете. В дальнейшем вы научитесь писать скрипты – так вот, вместо самих команд пишите скрипты, которые выполняют строго заданные функции и указывайте в sudoers эти скрипты вместо команд. Ну и у sudo еще много всяких настроек, которые я не рассмотрел – но для основ этого будет достаточно.