Как моделируют Windows как подсказка пароля администратора в Linux?

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

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

Если вы работаете в терминале и хотите запустить команду от имени пользователя root с помощью su , выполните:

su -c 'somecommand an_argument another_argument'

С помощью sudo :

sudo somecommand an_argument another_argument

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

Вы также можете получить графическое приглашение для ввода пароля (с помощью gksu , kdesu ,…), но если вы уже работаете в терминале, это менее удобно.

Помня о том, что бесплатных блюд не бывает, можно минимизировать риск.

Если вы хотите запускать свой скрипт от имени root и сразу же выходить без запроса пароля и команды exit, то вам придется пойти на небольшой компромисс.

Следующее решение позволяет хранить ваш дважды (или более) зашифрованный root пароль в любом месте с текущими правами пользователя.

Высокий уровень:

1. Шифрование root пароля в base64 дважды один раз и размещение файла в любом месте (может быть 1234.txt, например).

2. Вызываем скрипт expect с аргументом (расшифрованная строка сверху)

3. Expect запускаем нужный скрипт и выходим.

4. Файл очистки под /root, вызванный из expect, удаляет bash_history (обычного пользователя) строки, содержащие root, зашифрованный паролем файл и base64. Для удаления любых следов был вызван скрипт (с точки зрения обычного пользователя). Этот скрипт доступен только пользователю root.

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

Более того, двойное base64 шифрование, кажется мне довольно случайным и невинным (хотя я не эксперт по безопасности, я бы не распознал его как 2xbase64). Например:

V1c5MVFYSmxWMlZzWTI5dFpRbz0K decrypted to YouAreWelcome 

Кодируем пароль дважды в base64 1 раз:

$ cat pass.txt | base64 | base64 > innocent_name.txt
$ rm pass.txt

Затем:

Запускаем скрипт:

$ ./root_wrap.exp "$(cat innocent_name.txt | base64 -d | base64 -d)"

Ожидаемый скрипт:

#!/usr/bin/expect -f

set root_user root;
set root_pass [ lindex $argv 0 ];

spawn bash
expect "*$ "
send -- "whoami\r"
expect "*$ "
send -- "su $root_user\r"
expect "*?assword:*"
send -- "$root_pass\r"
expect "*# "
send -- "./whoam.sh\r"
expect "*# "
send -- "/root/rm_trace.sh\r"
expect "*# "
send -- "exit\r"
send -- "whoami\r"
expect "*$ "
expect eof

Скрипт очистки истории /root/rm_trace.sh:

#!/bin/bash

sed -i '/base64/d' /home/<user>/.bash_history
sed -i '/root_wrapp/d' /home/<user>/.bash_history
sed -i '/innocent_name/d' /home/<user>/.bash_history

Образец bash скрипта для запуска от имени root:

 #!/bin/bash

 echo "now running as root"
 whoami