/ usr / bin / env как шебанг - и его последствия для безопасности [дубликат]
Необходимо дождаться обновления ядра:
Что касается 16:17 (GMT -3), пакеты с исправлением выпущены не были:
[root@centos7 ~]# yum upgrade
Loaded plugins: fastestmirror
base | 3.6 kB 00:00:00
extras | 3.4 kB 00:00:00
updates | 3.4 kB 00:00:00
Loading mirror speeds from cached hostfile
* base: centos.ar.host-engine.com
* epel: archive.linux.duke.edu
* extras: centos.ar.host-engine.com
* updates: centos.ar.host-engine.com
No packages marked for update
[root@centos7 ~]# rpm -q --changelog kernel | grep -i CVE-2016-5195
[root@centos7 ~]# uname -a
Linux centos7.tbl.com.br 3.10.0-327.36.2.el7.x86_64 #1 SMP Mon Oct 10 23:08:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
То же самое относится и к CentOS6.
Существует обходной путь для этой проблемы с использованием systemtap , но кажется, что он просто работает, если вы используете ядро с включенной debuginfo .
tl, dr : Дождитесь обновления ядра. Другие дистрибутивы уже применили патч.
«что, если кто-то заменит этот исполняемый файл своим собственным в, скажем, ~ / .local / bin?
Тогда сценарий для них не работает.
Но это не так. имеет значение, поскольку они могут потенциально сломать сценарий для себя другими способами или запустить другую программу напрямую, не вмешиваясь в PATH или env .
Если у ваших пользователей нет other каталоги пользователей в их ПУТИ или могут редактировать ПУТЬ других пользователей, на самом деле нет никакой возможности, чтобы один пользователь испортил другой.
Однако, если бы это было не так. это не сценарий оболочки, а что-то, что предоставляет дополнительные привилегии, например, оболочку setuid для некоторой программы, тогда все будет иначе. В этом случае было бы необходимо использовать абсолютный путь для запуска программы, поместите ее в каталог, который непривилегированные пользователи не могут изменить, и очистите среду при запуске программы.
Здесь нет угрозы безопасности. / usr / bin / env должен выбрать соответствующий двоичный файл в соответствии со средой пользователя. Поэтому, если пользователь установил свой собственный bash в ~ / .local / bin , то / usr / bin / env действительно должен попытаться использовать его (они может, например, скомпилировать версию с дополнительными функциями, которые недоступны в общесистемной версии, и предпочел бы использовать ее вместо общесистемной версии). То же самое и с любым другим двоичным интерпретатором. Нет никакого риска для безопасности, потому что пользователь не сможет запустить то, что он все равно не смог бы запустить.
Что касается того, почему замена не работает в вашем случае, я сомневаюсь, что это имеет какое-либо отношение к / usr / bin / env . Попробуйте запустить PATH = ~ / .local / bin bash , PATH = ~ / .local / bin bash (как это будет вызываться при запуске script) и PATH = ~ / .local / bin / usr / bin / env bash и посмотрите, какой из них не работает. Это должно дать представление о том, к чему относится ошибка «файл не найден».
Что касается разницы в поведении shell и perl, perl в отличие от shell проверяет первую строку, чтобы определить, что запускать:
$ cat tcl
#!/usr/bin/env tclsh
puts "TCL running as [pid]"
$ perl tcl
TCL running as 39689
$ cat sbcl
#!/opt/local/bin/sbcl --script
(format t "~a running as ~a~%" 'lisp (sb-unix:unix-getpid))
$ perl sbcl
LISP running as 39766
$
Использование этой возможности включает написание тестов на каком-нибудь другом языке, кроме perl, так что можно иметь TAP-совместимые скрипты на других языках, и prove или что-либо еще будет выполнять их правильно.