То, как предотвратить сценарии/команды, угнав Вашу сессию, кэшировало sudo способность?

Question 1

Если я выполняю a sudo команда это попросит у меня пароля, однако на том Терминальном сеансе в течение следующих нескольких минут, которые это позволит мне выполнять sudo команды, не прося у меня пароль, поскольку это будет кэшировать это, мне разрешают.

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

Но то, что я недавно нашел, было чем-то довольно тревожным, если я создаю немного сценария как это, например:

#!/bin/bash

sudo rm -rf /

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

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

Так мои вопросы, это возможный сделать его так, чтобы я мог работать sudo команды и это будут кэшировать его для меня, но затем если я запущу скрипт не с sudo для сценария, чтобы не смочь просто угнать ту способность? Я понимаю, что меня выполняющий сценарий в основном то же как я просто выполнение команд в сценарии в порядке, который они там, но есть ли не способ сделать что-то умное так, чтобы это работало немного отличающимся способом или так, чтобы sudo ограничивается для скриптов, которые я запускаю?

Действительно что-либо, хотя это я не работал с sudo не должен мочь выполнить вещи с sudo. Включая команды. Если они только угоняют кэшируемую способность, которая является...

Я выполняю Ubuntu GNOME 15.10 с GNOME 3.18.

У меня есть предложение для того, как это могло быть сделано, но я не знаю практичность этого: я мог сделать его так, чтобы, когда я выполняю команду и она начала выполнять его, это регистрируется, это в файл (как сделан со всеми Терминальными командами хотя, возможно, немного слишком поздно для этого - с history команда) и затем когда sudo выполняется это проверяет, выполнил ли я ту команду в Терминале (с помощью журнала, который регистрируется, когда я делаю), и если не затем предполагается, что это не мной так, это предлагает мне пароль?

Question 2

Можно работать

sudo -k

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

Вот способ сделать то, что Вы хотите (я думаю).

Перемещение Ваш sudo в другом месте:
```
mv /usr/bin/sudo /usr/bin/sudo_real
```

Помещенный следующее в usr/bin/sudo:

#!/bin/bash -i
# Allows 'sudo' to be run with cached credentials from the command line,
# but clears the cache if run from within a script.
# Get the last command executed manually from the history
LAST_COMMAND=`history | tail -n 1 | cut -c 8-`

if [[ "${LAST_COMMAND}" == "sudo "* ]]; then
    # The last command was 'sudo' - i.e. the user ran sudo 
    sudo_real "$@"
else
    # The last command was NOT sudo - so this sudo was called from within a script.
    # Force the cached credentials to be cleared. 
    sudo_real -k "$@"
fi

Делают новое /usr/bin/sudo исполняемый файл:
```
chmod a+x /usr/bin/sudo
```
Псевдоним sudo для обновления истории удара, когда Вы выполняете его от оболочки путем помещения этого в Ваш ~/.bashrc:
```
alias sudo="history -a;sudo"
```

Теперь, когда ВЫ работаете sudo ..., это поместит sudo ... в историю удара, и сценарий будет находить его и работать sudo_real. Но когда другой сценарий работает sudo, это не будет в истории, и это будет звонить sudo_real -k.

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

Question 3

Question 4

Моя позиция по этой проблеме - это: если Вы не уверены, можете ли Вы или не можете запустить приложение с корневым полномочием, в то время как Ваши учетные данные все еще не испытали таймаут, то просто отключают тайм-аут вообще, сделайте его 0. Конкретно Вам нужна эта установка в Вашем /etc/sudoers файл:

Defaults    timestamp_timeout=0

Страница справочника определяет его как так:

 timestamp_timeout
                   Number of minutes that can elapse before sudo will ask
                   for a passwd again.  The timeout may include a frac‐
                   tional component if minute granularity is insufficient,
                   for example 2.5.  The default is 15.  Set this to 0 to
                   always prompt for a password.  If set to a value less
                   than 0 the user's time stamp will never expire.  This
                   can be used to allow users to create or delete their
                   own time stamps via “sudo -v” and “sudo -k” respec‐
                   tively.

Однако, если Вы намереваетесь быть благоразумными, можно определить следующую функцию в .bashrc

sudo_check()
{
  real_path="$( realpath $1 )"
  file "$real_path" | grep -q -i script
  if [ $? -eq 0 ]; then
     grep -q 'sudo' "$real_path"  && \
     { echo '>>> ALERT: Its a script that requests sudo';
       echo '    resetting sudo timestamp';
       echo 'please rerun with sudo appended ';
     }
     sudo -k
  else
     sudo "$@"
  fi

}

, Эта функция проверит, содержит ли сценарий вызов к sudo, и предупредите Вас этого. Рев является примером того, что я выполнял ту функцию на сценарии (который является моим преобразователь фона экрана входа в систему между прочим)

$ sudo_check sergrep/chgreeterbg.sh                            
>>> ALERT: Its a script that requests sudo
    resetting sudo timestamp

Question 5

Как можно дифференцироваться между сценарием и исполняемой двоичной командой?

, Конечно, можно ли думать об определении функции, названной sudo, который будет иметь проверки работоспособности прежде, чем выполнить фактический двоичный файл, но

, Поскольку сценарий может иметь какое-либо имя, что, если сценарий имеет имя как ls? Так проверка расширения как .sh не поможет
Также хижина чтения, поскольку первая строка сценария не поможет также, потому что сценарий может работать, не имея хижины

, я думаю, если Вы слишком параноики об этом, можно думать об отключении пароля, кэширующегося в целом путем создания псевдонима как:

alias sudo='sudo -k'

и помещенный это в Ваш ~/.bashrc.

muru · Accepted Answer · 1 December 2019 в 13:06