“sudo su -”, рассмотрел плохую практику?
Фон
Я знаю различие между su -, sudo su -, и sudo <command>:
su -- пользователь переключателей для укоренения, требует пароля rootsudo su -- пользователь переключателей для укоренения, требует только пароля текущего пользователяsudo <command>- предоставляет корневой доступ только для определенной команды; требует только пароля текущего пользователя
Мой вопрос о действительно ли использование sudo su - безопасная практика в продуктивной среде.
Некоторые мысли:
Это походит на разрешение
sudo su -излагает угрозу безопасности путем создания доступа к корневой учетной записи зависящим от паролей отдельного пользователя. Конечно, это могло бы быть смягчено путем осуществления строгой политики паролей. Я не думаюsu -немного лучше, так как это потребовало бы, чтобы администратор совместно использовал фактический пароль root.Разрешение пользователям полностью переключиться на корневую учетную запись делает более трудным отслеживать то, кто вносит изменения в систему. Я видел случаи в своем дневном задании, где многочисленным пользователям дают
sudo su -доступ. Первая вещь, которую пользователи делают при вхождении в систему, выполняетсяsudo su -, перед начинающейся работой. Затем однажды что-то повреждается, и нет никакой трассируемости тому, кто работалrm -rf *в неправильном каталоге.
Вопросы
Данный вышеупомянутые проблемы, это когда-либо хорошая идея позволить пользователям использовать sudo su - или даже su - вообще?
Есть ли любые причины, для которых администратор настроил бы учетные записи пользователей sudo su - или su - вместо sudo <command> (кроме лени)?
Примечание: Я игнорирую регистр где пользователь, работающий sudo su - или su - Администратор должен внести системные изменения, когда прямой ssh доступ был отключен для пользователя root.
Давайте посмотрим на примеры:
su -
запустит /bin/sh от имени пользователя root, использующего корневое окружение. Пароль root необходим, и запись в журнал MAY будет производиться в зависимости от настроек syslog (обычно по умолчанию в /var/log/auth.log).
sudo /bin/sh
запустит оболочку от имени пользователя root, используя текущий набор переменных окружения (за некоторыми исключениями, как это будет определено в файле sudoers). Пароль - это исходный пароль пользователя, а НЕ пароль пользователя root. sudo обычно записывается в журнал.
sudo su -
запустит оболочку (обычно /bin/sh) от имени пользователя root, настраивающего окружение от имени пользователя root. Для этого потребуется пароль пользователя-источника, и он обычно будет записан в журнал.
Иногда необходимо иметь окружение root над вашим собственным окружением, поэтому su - подходящий метод. Помните, что sudo все равно будет регистрировать использование команды оболочки в любом случае.
*Вышеизложенные опасения - это когда-нибудь хорошая идея, чтобы позволить пользователям используйте sudo su *
Нет, на мой взгляд, нет. Это не имеет никакого практического преимущества по сравнению с разрешением su, за исключением того, что для этого им не нужен пароль root.
или su - вообще?
Так как я всегда отключаю вход в систему с правами root, su необходимо и, в целом, делает сервер более безопасным.
. OP, кажется, предоставляет множество веских причин не разрешать / поощрять общее использование для запуска sudo bash или sudo su - , поскольку это переключает их к всесильному режиму, внутреннее устройство которого обычно не регистрируется. И они могут забыть, что находятся в этом режиме, и сделать что-то ... прискорбное.
Таким образом, кажется более безопасным, чтобы большинство пользователей ограничивалось запуском sudo on / a / specific / command / или list команд. Таким образом регистрируется каждая команда sudo.
Будете ли вы сталкиваться с исключениями на практике? Конечно. Будет ли реакция на такие исключения возвращением к ленивой практике неограниченного sudo su - вероятно, нет.