su или sudo?

    С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации Ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano, а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root'ового шелла предлагается писать sudo su -. Попробую объяснить, почему такое положение вещей кажется мне неправильным.

    Исторически единственным универсальным способом выполнить команду от имени другого пользователя в Unix была программа su. Запущенная без параметров, она запрашивала пароль суперпользователя и в случае успеха просто подменяла текущее имя пользователя на root, оставляя почти все переменные окружения от старого пользователя (кроме PATH, USER и еще пары-тройки, см. man su от своего дистрибутива). Более корректно было запускать ее как su - — в таком случае оболочка получала также и правильный environment. С параметром -c можно было выполнить команду: su -c "vim /etc/fstab".

    При этом доверенным пользователям приходилось помнить пароль root'а и у всех пользователей, перечисленных в группе «wheel» (т.е. в группе, члены которой могли выполнить команду su и стать суперпользователем), был одинаковый неограниченный доступ ко всей системе, что являлось серьёзной проблемой безопасности.

    Затем появилась команда sudo, и это был прорыв. Теперь администратор мог указывать список разрешенных команд для каждого пользователя (или группы пользователей), файлы, доступные для редактирования, специальные переменные окружения и многое другое (все это великолепие управляется из /etc/sudoers, см. man sudoers от своего дистрибутива). При запуске sudo спрашивает у пользователя его собственный пароль, а не пароль root. Полноценный шелл можно получить с помощью "sudo -i"

    Стоит особо упомянуть о специальной команде sudoedit, безопасно запускающей редактор, указанный в переменной окружения $EDITOR. При более традиционной схеме редактирование файлов производилось примерно так:
    sudo vi /etc/fstab


    Запускаемый таким образом vi наследовал оболочку с неограниченными правами и через :! пользователь мог запускать любую команду (если, конечно, админ не позаботился об этом заранее) и открыть любой файл.

    sudoedit проверяет, можно ли этому пользователю изменять данный файл, затем копирует указанный файл во временный каталог, открывает его в редакторе (который наследует права пользователя, а не root'а), а после редактирования, если файл был изменён, с особыми предосторожностями копирует его обратно.

    В Debian-based дистрибутивах пользователь root не имеет пароля, вместо этого все административные действия должны производиться через sudo или его графический аналог gksudo. Являясь полной заменой su, sudo должна бы быть единственной командой переключения между пользователями, однако, как было сказано вначале, в настоящий момент это не так и все зачем-то изобретают дикие последовательности из sudo, su, vi и черточек.

    Поэтому предлагаю всем раз и навсегда запомнить:
    что хотим сделать? правильно неправильно
    выполнить команду от имени root sudo command su -c «command»
    отредактировать файл от имени root sudoedit file su vim file
    sudo vim file
    получить оболочку root sudo -i su -
    sudo su -

    После первой публикации этой заметки мне было задано несколько вопросов. Из ответов получилось сделать мини-FAQ.

    Q: как с помощью sudo сделать su -c "echo 1 > /etc/privileged_file"? sudo echo 1 /etc/privileged_file ругается на «permission denied»
    A: Это происходит потому, что только команда echo выполняется в повышенными правами, а результат перенаправляется в файл уже с правами обычного пользователя. Чтобы добавить что-нибудь в privileged_file, нужно выполнить такую команду:
    $ echo 1| sudo tee -a privileged_file >/dev/null
    

    Или же временно стать рутом:
    $ sudo -i
    # echo 1 > privileged_file
    # exit
    $ 
    

    Q: sudo -i длиннее, чем su -, а разницы между ними вроде как и никакой, зачем печатать больше?
    A: У sudo есть несколько преимуществ, ради которых стоит потрудиться набрать несколько лишних символов:
    • по умолчанию sudo записывает всю пользовательскую активность в syslog-канал authpriv (как правило, результат кладется в файл /var/log/auth.log), а в su подобную фичу надо включать с помошью задания специального параметра в файле настроек, различающемся от дистрибутива к дистрибутиву (SULOG_FILE в /etc/login.defs в Ubuntu Linux, /etc/login.conf и /etc/pam.d/su в FreeBSD и т.д.)
    • в случае с su администратор системы не может ограничить команды, выполняемые пользователями, а в sudo — может
    • если пользователь должен быть лишен права администрирования, в случае с su после удаления его из группы wheel он должен забыть пароль root'а; если используется sudo, достаточно вынести его из соответствующей группы (например, wheel или admin) и/или файла sudoers, если он был дополнительно настроен.
    Q: я единственный пользователь своей системы и привык к su, зачем мне sudo?
    A: отвечу вопросом на вопрос: если есть правильный sudo, зачем использовать устаревший su?
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 57
    • +7
      ну я так скажу :) каждый живет так как ему нравится. Меня полне устраивает su. И в очень редких случаях, даже незнаю почему пользуюсь sudo. Думаю и то и то имеет право на жизнь :)
      • +1
        ну что Вы, надо себя заставлять использовать правильные средства :-)
        • +5
          согласен. НО
          Ваши утверждения по поводу логов, кучи прав это все годится для какого нить сервера где это все очень важ, а для домашнего компа это совсем не принципиально :) мой пароль рута дома даже моя любимая жена знает, и умеет открывать рутовский шелл :)
          • +5
            зато потом на Большом Сервере не надо будет заново привыкать использовать sudo

            а если племянник в гости придёт, поизучает ~/.bash_history и понаделает делов в системе?
            • 0
              и что интересного он там в хистори найдет? туда ж пароли не пишутся…
              • +2
                иногда пишутся, если команду su пишешь неправильно или enter забываешь нажать
                • +2
                  да, убедительный аргумент :) хотя мало вероятно что хистори ктото будет смотреть, всеже вы правы :) перехожу на sudo.
                  Но если использовать sudo точно такая же ситуация может возникнуть, правда пароль не рутовский будет.
                  • 0
                    Пароль может быть кстати быть и рутовским. Например, в последних SuSE, если вы задаете руту пароль, то по-умолчанию sudo будет в качестве пароля хотеть именно пароль рута.

                    С другой стороны, если комп домашний, и все равно все знают рутовский пароль, то почему бы не облегчить жизнь с NOPASSWD? В некоторых случаях здорово экономит время. Собственно ради этого самого NOPASSWD я чаще всего sudo и юзаю.
                  • 0
                    иногда и очистить можно — главное заметить вовремя (:
                • +5
                  Да ладно, при физическом доступе к компьютеру можно сделать что угодно. Загрузился с флешки и в путь.
          • +2
            su лучше не пользоваться, можно засветить пароль рута, а для sudo можно настроить ограниченные права.
            • 0
              Спасибо. Хорошо пишете. Новичкам будет полезно.
              Пару дней назад успел прочитать в вашем блоге — bappoy.pp.ru/2008/11/10/su-vs-sudo.html
              • 0
                Если уж про линуксы в общем: на моих центосах аналогичный эффект достигается через «sudo -s»; вместо sudoedit используется visudo.
                У «sudo su -», кстати, есть одно отличие — чистит терминал после завершения.
                • +2
                  sudo -i иногда правильнее, поскольку наследуется рутовое окружение, а не пользовательское, которое может содержать кривые переменные окружения (например, лишние каталоги в PATH)
                  visudo работает только с /etc/sudoers
                  насчет чистки терминала думаю, что это настраивается добавлением clear в конец /root/.bashrc
                  • +1
                    Скорее, .bash_logout
                    • 0
                      Действительно, -i тоже есть в более поздних версиях (а я даже в ман заглянул, чтоб ещё раз убедиться, что этого параметра там нет… на некоторых серверах).
                      Касательно очистки терминала — смысла делать это при запуске шелла никакого, а при выходе бывает полезно; правильное решение уже написали.
                    • 0
                      visudo — это «правильное» редактирование /etc/sudoers, и для других файлов, в отличие от sudoedit оно не подходит
                    • +1
                      > если пользователь должен быть лишен права администрирования, в случае с su он должен забыть пароль root'а; если используется sudo, достаточно вынести его из соответствующей группы (например, wheel или admin) и/или файла sudoers, если он был дополнительно настроен.

                      Вот это — ерунда. Для использования su пользователь тоже должен быть в группе wheel. Доказательство:
                      gw.office.rterm.ru merlin # cat /etc/pam.d/su
                      #%PAM-1.0

                      auth sufficient pam_rootok.so
                      auth required pam_wheel.so use_uid
                      auth include system-auth

                      account include system-auth

                      password include system-auth

                      session include system-auth
                      session required pam_env.so
                      session optional pam_xauth.so

                      Модуль pam_wheel.so проверяет, является ли пользователь членом группы wheel.
                      • 0
                        Да, Вы правы.
                        Просто это казалось мне настолько очевидным, что я как-то забыл об этом написать :)
                        • +1
                          поправил, спасибо за замечание
                          • 0
                            pam_wheel.so в качетсве параметра может принимать иям группы к которой должен принадлежать пользователь. МОжно даже трбовать членства в двух и более группах сразу. У меня su может выпольнять только пользователь принадлежащий специальной группе.
                            • 0
                              так легко — несколько pam_wheel.so, каждый из них required и разные группы в аргументах. Вход разрешит, только если пользователь входит во все группы.
                            • 0
                              Проблема с su на мой взгляд именно в том, что если пользователя исключили из wheel, то он все равно знает пароль суперпользователя и, как правило, его логин.
                              • 0
                                Если речь идёт про машину, к которой есть физический доступ — он вообще сможет сбросить пароль рута, если захочет. Загрузится с флешки и вперёд. Т.е. знание или незнание пароля рута не остановит.
                                • 0
                                  (рано нажал)
                                  А если нет физического доступа — знание пароля рута ему наоборот не поможет, т.к. все нормальные системы запрещают непосредственный логин рута через сеть (скажем, есть опция permit root login в openssh, также есть ограничения в nfs и других).

                                  Т.е. знает он — и что это вообще меняет?
                                  • 0
                                    Много что меняет. Появляется возможность, имея физический доступ, скрытно предоставить сетевой доступ, например. Даже если сингл режим отключен. И т.д. Вобщем появляются возможности разные. Да и не везде ограничен сетевой доступ. Рут мог для своего удобства открыть скажем. В общем на мой взгляд — проблема имеется.
                                    • 0
                                      Да не проблема — я могу не сбивать пароль рута, а, например, chrootиться и делать под рутом что угодно, не зная его. Могу сделать ещё одного пользователя с uid=gid=0, с известным мне паролем. Короче, повторю, при физическом доступе нет разницы, знаешь или не знаешь пароль рута, так что «незнание рутового пароля» абсолютно ничего не решает.
                                      Тем более, что я могу точно так же сбросить пароль «нерута», а пользователя с правом делать sudo, и работать от его имени через sudo.

                                      > Да и не везде ограничен сетевой доступ. Рут мог для своего удобства открыть скажем.
                                      Во-первых, кроме ограничений по uid/gid, бывает ещё куча других — ограничения внутри демонов, ограничения типа selinux или apparmor, ограничения файерволлом и т. д.
                                      Во-вторых, в реальных системах «рутов» всегда несколько (опустим случай «своего админа» в мелкой конторке — они уже вымирают, и вымрут в течение лет трёх, в пользу аутсорсеров). Не может один человек обслуживать сложную сеть, да и иногда ему нужно уходить в отпуск, или он может заболеть…
                                      В третьих, если человек идиот не запрещает такой доступ от имени рута через сеть (для удобства или ещё почему-нибудь), никакое sudo вместо su его точно не спасёт. Рут — это как бы «мастер-пароль» для изменения настроек, а никак не «отдельный пользователь-администратор».

                                      В целом, sudo не добавляет безопастности по сравнению с su, когда мы говорим о выполнении административных задач (сомневающиеся могут попробовать привести ситуацию, в которой оно добавило бы безопастности). sudo было придумано совершенно с другой целью, а именно — «предоставление доступа рядовому пользователю к отдельным командам, требующим прав суперпользователя». Скажем, разрешить ему тушить систему командой sudo shutdown -r now.
                                      • +1
                                        Господи, да что-ж вы такой? Никто и не спорит что против квалифицированного злоумышленника разницы в использовании su или sudo нет. Но вы же автомобиль свой открытым на улице не оставляете, из-за того что «если захотят угнать — все равно угонят»? Знание пароля суперпользователя во-первых может облегчить процесс компроментирования системы, во-вторых спровоцировать этот процесс.
                              • 0
                                Изначально учился пользоваться sudo, и в целом согласен с автором,
                                непонятно одно — почему неправильно писать sudo vim file?
                                sudoedit file — это редактор по умолчанию, а если нужен(хочется) vim — то почему же это не правильно?
                                • 0
                                  потому что vim, будучи запущенным в таком виде, позволяет выполнять выполнять команды от имени суперпользователя
                                  а это иногда хочется ограничить

                                  установить vim редактором по умолчанию можно, добавив export EDITOR=vim в ~/.bashrc, так что никаких сложностей тут нет
                                • 0
                                  сори за офтоп, спасибо за статью. всегда пользовался su. открыл для себя что sudo -i подтягивает права не только локального рута а и права из домена, то есть, в хоть домене я доменный администратор, а на локальной машине просто пользователь с унином больше 10000 (добавить в группу wheel нельзя ). права доменного администратора подтянулись сразу без вопроса о пароле (авторизация через домен)
                                  • 0
                                    Никогда sudoedit не пользовался, а вот сервисы из sudo vim перезапускал, и удивлялся тому, что такая потенциальная дыра есть, теперь всё встало на свои места. Спасибо.
                                    p.s. Сейчас запустил sudoedit, ужаснулся и пошёл менять редактор не более привычный. =)
                                    • 0
                                      ммм странно, а у меня в дебиане root был. )
                                      • 0
                                        Спасибо за статью. У меня на десктопе Kubuntu, где я использую sudo всегда, как Вы и предлагаете, а вот в openSuse всегда использую su, так как если вводить sudo <программа с граф. оболочкой>, то пишет «Cannot to connect X-server». Не знаете из-за чего это?
                                        • 0
                                          знаю, почитай чуть ниже.
                                        • 0
                                          Единственный, на мой взгляд, недостаток sudo — это то, что получив каким-либо способом
                                          пароль пользователя, злоумышленник автоматически получает и все его привелегии, гарантированные в sudoers, и как вариант полный рут доступ. Что в случае с su было бы значительно сложнее.
                                          • 0
                                            Не совсем. Можно дать юзерам второй логин типа vasya-su с другим паролем, или поставить пароль на рута, тогда пароли не будут совпадать.
                                            Данные послабления сделаны для однопользовательских систем.
                                            • 0
                                              Почему сложнее?
                                              • 0
                                                Перечитал Ваш комментарий еще раз, на этот раз понял правильно :)
                                              • 0
                                                А как sudo устроена? Считывает настройки один раз при входе в систему, или есть определённый демон?
                                                Вопрос — вот пользователь вошёл в систему, имея определённые настройки, и во время его пребывания в системе суперпользователь изменил набор комманд для него (к примеру рассширил). Пользователь сможет воспользоваться ими сразу? Или необходимо заново представиться системе? Или перезапустить сервис sudo?
                                                Просто по аналогии с .bashrc — набор команд-то я изменю, но пока я не «перезайду» они не применятся.
                                                <hr />
                                                Сеанс разговора с самим собой и консолью.
                                                Ага… Демон есть… Дату у файлов в /var/run/sudo/ меняет на 1/1/1985 — для того, чтобы после перезапуска нельзя было без ввода пароля пользователя запустить sudo.
                                                man sudo прямо-таки глаза раскрыл мне на эту замечательную команду.
                                                Для себя открыл опцию -v — продлить «время ожидания» ещё на 15 минут и при этом не выполнять никакой команды. И по прошествии этого времени спрашивать пароль опять (как и при первом запуске).

                                                -k же, наоборот, «убивает» () штамп времени и при следующем запуске sudo будет требовать пароль. Можно не волноваться за оставленную без присмотра консоль (а то есть тут у меня любители походить по клавиатуре :) ).
                                                • 0
                                                  Собственно перезапускать его не надо :) Настройки перечитываются при каждой попытке сделать sudo, на сколько я знаю.
                                                • +2
                                                  В Debian-based дистрибутивах пользователь root не имеет пароля
                                                  oh, rly? Или под deb-based автора подразумевает ubuntu-like?
                                                  • 0
                                                    Убунту — это и есть debian-based. Пока что Убунта не доросла до «ubuntu-like» :)
                                                    • +2
                                                      Я намекаю на то, что в самом debian, например, рутовый пароль есть.
                                                  • 0
                                                    Есть такая полезная штучка как пакет sux в дебианах. Позволяет наследовать X environment под su(можно например запустить броузер из-под другого юзера настроенный под особую безопасность). Так вот она построена на su, а на gksu/gksudo у меня не получилось сделать то же самое. Я слегка помучался, не обнаружил аналогичных параметров и все на том закончилось… Так, что в некоторых аспектах su пока рано списывать со счетов :)
                                                    • –2
                                                      Вот, правильно в Дебиане, мне тоже нравится когда для рута не задан пароль. Но мне не нравится заморочный файл sudoers. Почему для тех, кто не хочет возиться с конфигами. нельзя было сделать версию sudo без конфига?
                                                      • 0
                                                        >отвечу вопросом на вопрос: если есть правильный sudo, зачем использовать устаревший su?

                                                        затем, что если кто-то узнал ваш пароль (который большинство используют где попало), злоумышленник получает рутовый доступ.
                                                        а в случае с su, есть ещё один уровень защиты — сложный (зачастую) рутовый пароль.

                                                        • 0
                                                          как бывший виндузятник и любитель гуев делаю
                                                          ssh root@localhost -X
                                                          • +2
                                                            Насчет «устаревшего» su vs «правильного» sudo — чепуха.

                                                            Вообще-то у su и sudo разное предназначение: su — для предоставления пользователю дополнительных прав вообще, sudo — для выполнения ограниченного набора действий.

                                                            Как su, так и sudo умеют спрашивать и пароль текущего пользователя, и пароль цели (man suauth, pam_pseudo).

                                                            Отдайте sudo пользователям, а su — администраторам.
                                                            • 0
                                                              «В Debian-based дистрибутивах пользователь root не имеет пароля»

                                                              Как это не имеет? Сначала он просто не установлен. Загрузился в консоли под root, ввел passwd, поставил пароль. А то так любой зашедший к тебе домой «шутник» поставит его за тебя.
                                                              • 0
                                                                использую sudo. хотя вот только что нашел по теме: boxtor.ru/%d1%80%d0%b0%d0%b7-%d0%b8-%d0%bd%d0%b0%d0%b2%d1%81%d0%b5%d0%b3%d0%b4%d0%b0-%d1%80%d0%b0%d0%b7%d0%b1%d0%b5%d1%80%d0%b5%d0%bc%d1%81%d1%8f-%d1%81-root%d0%be%d0%bc-%d0%b8-sudo/
                                                                • +1
                                                                  Уважаемый, bappoy, не могли бы вы просвятить меня по следующему вопросу:
                                                                  у меня в моей домашней директории есть файлик .vimrc, в котором написано всё, чтобы vim был красавчегом. Прочитав вашу статью решил пользоваться командой sudoedit. Но косяк в том, что даже скопировав мой .vimrc в домашнюю папку рута и поставив ему в качестве дефолтного редактора vim, я, при редактировании файлов командой sudoedit не вижу, что применены настройки лежащие в .vimrc. Т.е.:

                                                                  $ vim some_script.php # всё красиво, всё подсвечено
                                                                  #vim some_script.php # всё красиво, всё подсвечено
                                                                  $sudoedit some_script.php # всё серо и некрасиво… что делать?
                                                                  • 0
                                                                    проверьте, что переменная EDITOR начального пользователя тоже установлена в vim
                                                                    • 0
                                                                      zeleniy@zeleniy-laptop:~$ whoami
                                                                      zeleniy
                                                                      zeleniy@zeleniy-laptop:~$ env | grep -i editor
                                                                      EDITOR=vim
                                                                      zeleniy@zeleniy-laptop:~$ sudoedit workspace/eclipse/php/XML_Generator/Tag.php
                                                                      [sudo] password for zeleniy:
                                                                      sudoedit: workspace/eclipse/php/XML_Generator/Tag.php unchanged # и вот здесь всё серое и без подсветки.

                                                                      Надеюсь я правильно вас понял )
                                                                      • 0
                                                                        может, в /etc/sudoers установлена переменная editor, которая ограничивает список допустимых редакторов, и vim нет среди них? вообще проверьте, может, это vi запускается вместо vim?
                                                                  • 0
                                                                    А в скриптах что использовать? Когда надо не простому пользователю стать рутом, а, наоборот, из рутового скрипта — стартового, или в кроне, запустить других скриптов от других пользователей?
                                                                    • 0
                                                                      sudo -u user -c <команда>

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое