Почему su для root вместо входа в систему как root?

33

Я часто слышал, что лучше использовать su для получения root-прав, а не входить напрямую как пользователь root (и, конечно, люди также говорят, что еще лучше использовать sudo). Я никогда не понимал, почему одно лучше, чем другие, понимание?

thepocketwade
источник
2
Вы думаете о ssh логинах или также логинах с физической машины?
Телемах

Ответы:

43

Вывод только suили sudoкогда требуется.

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

Тем самым вы уменьшаете возможности для опасных ошибок (плохие сценарии, неуместные подстановочные знаки и т. Д.) И уязвимостей от любых приложений, которые вы используете. Особенно те, которые подключаются к Интернету - см. Старую поговорку «Не IRC как root» .

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

Соблюдая эти правила, вы также можете отключить удаленный вход в систему. Это увеличивает полосу входа для любого потенциального злоумышленника, поскольку он должен был бы скомпрометировать как обычную учетную запись пользователя, которая была членом группы «wheel» и в идеале авторизованную только открытыми ключами SSH, так и саму корневую учетную запись.

Дэн Карли
источник
1
Не могли бы вы объяснить, почему удаленный вход в систему root является «достаточно большой уязвимостью».
thepocketwade
5
Поскольку, учитывая, что весь мир знает имя пользователя («root»), это просто вопрос определения пароля. И они могут сделать это грубой силой и захватить ваш компьютер.
Шалом Креймер
2
Еще одно преимущество sudo: регистрация выполненных команд.
Мануэль Фо
Это одитинг;)
Дэн Карли
1
Хотя sudoэто и лучше, но suтакже позволяет вам использовать -mфлаг, чтобы переменные среды оставались неизменными, пока вы находитесь в корневом терминале. Ничто не побуждает меня больше помешаться, чем suнемного подручиться, только сделать что-то с ~именем каталога и заставить его не работать.
tj111 28.09.09
27

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

Плюс это создает ответственность. :)

egorgry
источник
+1 коротко и по существу
lexu
15

Основная причина заключается в создании контрольного журнала. Если вам нужно войти в систему как обычный пользователь, а затем su, можно отследить, кто отвечает за данные действия.

Тим
источник
После того, как кто-то запустил su - root, как вы определяете, какие команды они выполняли? Это где-то зарегистрировано?
Добес Вандермер
10

sudo также автоматически регистрирует каждую команду в системном журнале, и вы можете определить команды, которые может использовать каждый пользователь.

Jure1873
источник
3
Что касается ведения журнала: это относится к каждой команде, которой предшествует «sudo», но в случае, когда sudo используется для перехода к корневой оболочке, команды регистрируются только в традиционных областях (в частности, в истории оболочки).
Зенхем
2
Действительно, sudo vim foo.txtзатем перетаскивание в оболочку изнутри vim даст вам корневую оболочку без обычной регистрации в sudo.
Офидиан
Или просто sudo -iполучить интерактивную сессию ...
Камил Кисиэль
Я не понимаю проблему с sudo vim foo.txt. Я запустил это, затем вышел из vim и все еще был собой, я что-то упустил?
thepocketwade
Вы можете «обмануть» sudo, чтобы получить оболочку, набрав sudo su - или sudo vim, а затем перейти к новой подоболочке. Но если вы используете sudo, потому что вы хотите, чтобы все регистрировалось в системном журнале (централизованно), и вы знаете, что его также можно использовать для получения другого подоболочки, тогда я не вижу в этом ничего плохого, это всего лишь бонус, если я не зависим только от этого.
Jure1873
9

Еще одна веская причина: при переходе с правами суперпользователя с помощью sudo пользователь проходит аутентификацию с использованием своих собственных учетных данных, что означает, что ему не обязательно указывать пароль root, что упрощает блокировку, когда кто-то покидает вашу организацию.

Zenham
источник
4

Если вы хотите создать контрольный журнал и не хотите стать жертвой проблем «sudo su -» или «sudo vim foo.txt», упомянутых здесь, вы можете использовать «sudosh». Раздайте root-доступ через sudo, но сделайте единственную допустимую команду для запуска sudosh.

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

mibus
источник
Это предполагает, конечно, что sudosh доступен в системе. Я только что проверил, и у меня нет ни на одном из моих коробок Linux.
Джон Гарденерс
Вы также можете использовать новый ksh93 с включенным ведением журнала аудита. Посмотрите эту статью на сайте IBM developerWorks: ibm.com/developerworks/aix/library/au-korn93/…
Мэй
Довольно легко обойти, просто запустив скрипт оболочки (который вы потом стираете). Создайте сценарий под безобидным именем как не прошедший аудит пользователя (или найдите его на своей рабочей станции), затем выполните sudo и запустите его. Вы могли бы даже действительно скрыть это, назвав его 'ls' или что-то подобное и поместив его в $ PATH (изменяя $ PATH, если необходимо), и заставить его выполнять свою грязную работу, вызывая / bin / ls, чтобы он выглядел нормально. Протрите его потом. Журнал аудита не будет знать, что / home / anthony / bin содержал «ls».
Дероберт
Да, это не идеально; мы знаем это - но это чертовски лучше, чем просто "sudo su -" ИМХО. И да, он не установлен по умолчанию нигде AFAIK. Однако он работает на Solaris и Linux довольно легко.
Мибус
1

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

Запретить удаленный root-доступ (или хотя бы root-доступ через пароли). (если вы разрешаете root-доступ через ключи, тщательно управляйте этими ключами или, что еще лучше, используйте что-то вроде kerberos, которое позволяет централизованно отзывать ключи).

Я бы отключил su и использовал sudo. Таким образом, пользователи используют ключи (желательно зашифрованные) для доступа к системе, затем они используют свой пароль только для повышения привилегий. Вы можете ограничить доступ к каким программам людям с помощью sudo, но в основном вы ограничиваете доступ только тем, кто знает пароль root.

В идеальном мире вы должны иметь возможность публиковать свои корневые пароли в Интернете, и это не имеет значения, даже если вы предоставили людям доступ к вашему компьютеру (но не поместили их в файл / etc / sudoers). Конечно, вы не должны публиковать пароль root, но идея в том, что вы защищаете свои системы с помощью концентрических уровней защиты.

Крис
источник
0

Идея состоит в том, чтобы отключить root-логин и, следовательно, не иметь учетной записи администратора по умолчанию. Таким образом, злоумышленник должен угадать имя пользователя и пароль (а не только пароль).

Johan
источник
0

Если вы используете root на регулярной основе, то ваши права доступа могут быть неправильными, или вам может потребоваться предоставить права sudo или права новой группы для r / w / x файлов или каталогов.

Хорошие схемы разрешений - это то, что даже давние пользователи Linux ошибаются или не осознают того, что имеют.

Даже не заводите меня на то, что сделал Ubuntu!

Эйден Белл
источник
-2

Он не позволяет запустить rm -r -f / Я только что выполнил это 2 дня назад (как непривилегированный пользователь, я хотел запустить rm -r -f *)

штуковина
источник
Принятый ответ уже содержал всю информацию.
Theuni