Я читал Ubuntu документация о root / sudo когда я наткнулся на следующее:
Разве sudo не менее безопасен, чем su?
Базовая модель безопасности одинакова, поэтому эти две системы имеют общие недостатки. Любой пользователь, использующий su или sudo, должен считаться привилегированным пользователем. Если учетная запись этого пользователя взломана злоумышленником, злоумышленник также может получить привилегии root в следующий раз, когда пользователь сделает это.
Как злоумышленник может получить привилегии root в следующий раз, когда это сделает пользователь? Предполагая, что sudo отключен.
На самом деле это очень просто. sudo обычно настроен на кэширование аутентификации, поэтому вам не нужно вводить пароль каждый раз, когда вы используете sudo по команде. Я считаю, что время кеширования по умолчанию составляет около 5 минут.
Таким образом, если злоумышленник имеет доступ к учетной записи пользователя с sudo доступ, даже не зная своего пароля, они могут просто дождаться следующего раза, когда пользователь выполнит sudo. Затем злоумышленник может запустить sudo сразу после этого и получить корневую оболочку.
Я предполагаю, что это тот сценарий, о котором они говорят, когда упоминают «в следующий раз, когда это сделает пользователь».
sudo -s выполняет пользователей .bashrc. Если у вас есть доступ к этой учетной записи, вы можете добавить строки в этот bashrc, который будет запускаться от имени пользователя root.
# ~/.bashrc
cp /bin/bash /bin/something_else
chmod 4755 /bin/bash
Я бы добавил что-то подобное, создал бы копию setuid bash, чтобы я мог запустить ее позже.
Редактировать: теперь кажется, что вопрос касается случаев, когда sudo не используется.
Первый трюк, который приходит на ум, если я хочу получить права root от пользователя, использующего su, - это изменить его путь.
# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
$ export PATH=/tmp:$PATH
su
# echo $PATH
/tmp:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
Это работает с Fedora 11 с bash 4. Конфигурации для su и среды оболочки в основном используются по умолчанию.
Как видите, я смог изменить путь как обычный пользователь, и этот путь не был сброшен su (примечание su - сбросил бы его). Измените их путь в их оболочке rc, а затем поместите мой собственный скрипт в новый каталог вверху пути. Сделайте несколько копий (или символических ссылок) с такими именами, как ls, cp, mv, вещи, которые часто запускаются.
#!/bin/bash
# make a shell for later
cp /bin/bash /bin/something_else
chmod 4755 /bin/bash
# cause more trouble
...
# now run the real command so the user doesn't notice
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
exec $0 $*
В любом случае, это всего лишь примеры, несомненно, есть и другие подобные сценарии. Я думаю, дело в том, что учетные записи, которые могут использовать su или sudo, требуют осторожности.
Я думаю, что дело, о котором вы спрашиваете, больше связано с повышением привилегий через su. Так как может оказаться, что скомпрометирован только пароль пользователя, злоумышленник не сможет сделать это, пока не получит пароль root. Если злоумышленник установит программу-кейлоггер или заменит su или что-то в этом роде, он / она сможет получить пароль root в следующий раз, когда привилегированный пользователь введет его.
Хотя sudo обычно используется вместе с командой su, думать, что sudo su - единственный способ сделать это, является ошибкой.
У sudo есть много опций для настройки того, что выполнять кем (пользователем ether или группой пользователей) на каком хосте. Мелкозернистый файл sudoers (или запись LDAP, если задействован sudo-ldap) вместе с умным мышлением системного администратора может привести к правилам, которые не могут поставить под угрозу безопасность системы, даже если учетная запись пользователя была взломана.
давайте посмотрим на реальный пример:
$ sudo -l
User exampleuser may run the following commands on this host:
(root) /opt/xmldns/gen.sh
(root) /usr/bin/make -C /root/admin
(root) /usr/sbin/xm list, /usr/sbin/xm dmesg
(root) /usr/sbin/zorpctl stop, /usr/sbin/zorpctl start, /usr/sbin/zorpctl status
(root) /etc/init.d/apache status, /etc/init.d/apache stop, /etc/init.d/apache start
(root) /usr/local/bin/protodump.sh httpreq
(root) /usr/sbin/xm console
$
Если кто-то не позволяет пользователю sudo-exec su / bash или другой оболочке ни напрямую (sudo su), ни косвенно (позволяя запускать редактор с root, который может использоваться для создания оболочки - в данном случае root), sudo - друг системного администратора и пользователей тоже.
Возвращаясь к вопросу в теме, если sudo отключено и su - единственный способ стать пользователем root в системе, можно было бы установить поддельную команду su (например, в ~ /.../ fakesu) и псевдоним, например alias su = ' ~ /.../ fakesu 'в rc-файле оболочки входа пользователя.
В этом случае простая команда su (поднять руку, которая использует / bin / su для вызова) в конечном итоге вызовет команду fakesu, которая может захватить пароль.
Если пароль пользователя скомпрометирован и у этого пользователя есть привилегии sudo, злоумышленник может запустить sudo su и стать пользователем root.
Принцип прост. Sudo требует только пароль пользователя для выполнения действий как root. Если кто-то смог взломать учетную запись этого пользователя, он, вероятно, знает пароль (или может легко его вычислить).
С su ситуация немного другая, потому что для этого требуется пароль root. Однако злоумышленник может изменить PATH пользователя, чтобы указать на его собственную версию su (внутри tmp или ./bin), которая где-то сохранит пароль root.
Теперь вы добавили, что sudo отключен. Ссылка, которую вы предоставили, не говорит об этом. Они упоминают случай, когда sudo или su настроены для этого пользователя, и злоумышленник использует это как рычаг для получения root.