Проверка командных двоичных файлов перед выполнением

Есть ли способы проверить, что вы на самом деле выполняете из bash-скрипта?

Предположим, что ваш Баш скрипт звонит несколько команд (например: tar, mail, scp, mysqldump) , и вы готовы , чтобы убедиться , что tarфактическая, реальная tar, которая может быть определена с помощью rootпользователя , являющегося владельцем файла и родительский каталог и только один с правами записи а не некоторые /tmp/surprise/tarс www-dataили apache2быть владельцем.

Конечно, я знаю об PATHокружающей среде, мне любопытно узнать, можно ли это дополнительно проверить из запущенного сценария bash и, если да, то как именно?

Пример: (псевдокод)

tarfile=$(which tar)
isroot=$(ls -l "$tarfile") | grep "root root"
#and so on...

Вместо проверки исполняемых файлов, которые вы собираетесь выполнить, вы можете запустить нужные двоичные файлы с самого начала. Например, если вы хотите убедиться, что не собираетесь запускаться /tmp/surprise/tar, просто запустите /usr/bin/tarваш скрипт. В качестве альтернативы, установите $PATHв здравом уме значение, прежде чем запускать что-либо.

Если вы не доверяете файлам /usr/bin/и другим системным каталогам, восстановить их невозможно. В вашем примере вы проверяете владельца ls, но откуда вы знаете, что можете доверять ls? Тот же аргумент применим к другим решениям, таким как md5sumи strace.

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

Если злоумышленник получил доступ к вашей системе и может изменить вашу $PATH(что не должно включать /tmpни при каких обстоятельствах), тогда уже слишком поздно беспокоиться о владельцах исполняемых файлов.

Вместо этого вы должны прочитать о том, как бороться с вторжением .

Лучше сосредоточиться на том, чтобы вообще избежать вторжения.

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

Это возможно в некоторой степени путем проверки md5sumфайла. Таким образом, в системах, которые используют aptуправление пакетами - в моем конкретном случае, Ubuntu 16.04 - есть файл /var/lib/dpkg/info/tar.md5sums, в котором хранятся суммы md5 всех файлов, полученных в tarходе установки. Таким образом, вы можете написать простое выражение if, которое проверяет, является ли выводmd5sum /bin/tar совпадает тем, что находится в этом файле.

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

Да, есть метод: встроенный type. В отличие от whichкоманды, которая выполняет поиск только в вашей переменной PATH, typeвы узнаете, является ли имя команды зарезервированным ключевым словом, встроенным, псевдонимом, функцией или дисковым файлом.

$ type -t foobar || echo "Not found"
Not found

$ type -t echo
builtin

$ enable -n echo; type -t echo; type -p echo
file
/usr/bin/echo

$ echo() { printf "(echoing) %s\n" "$*"; }; type -t echo
function

$ alias echo="/bin/echo 'I say: ' "; type -t echo
alias

Кроме того type -a, вам будут предоставлены все кандидаты в вашу команду (от первого до последнего выбора):

$ type -a echo
echo is aliased to `/bin/echo 'I say: ' '
echo is a function
echo () 
{ 
    printf "(echoing) %s\n" "$*"
}
echo is a shell builtin
echo is /usr/local/bin/echo
echo is /bin/echo

Наконец, если вас интересуют только двоичные файлы на вашем диске, вы можете использовать type -Paдля получения всех двоичных файлов в вашем PATH (в том же порядке, что и выше):

$ type -Pa tar
/home/me/bin/tar                <= oh oh, is this normal?
/bin/tar

Тем не менее, typeодин не скажет вам точно, какая команда будет вызвана в конце. Например, если у вас tarесть псевдоним, который вызывает двоичный файл (например alias tar="/tmp/tar"), он typeскажет вам, что это alias.

Вы можете проверить, какие команды в точности выполняются скриптом, используя strace. Например:

strace -f -e execve ./script.sh

С помощью следующего скрипта:

#!/bin/bash
touch testfile.txt
echo "Hello" >> testfile.txt
cat testfile.txt
rm testfile.txt

straceскажет вам точный путь к командам, выполняемым при использовании с -e execveпараметром:

execve("./script.sh", ["./script.sh"], [/* 69 vars */]) = 0 
Process 8524 attached
[pid  8524] execve("/usr/bin/touch", ["touch", "testfile.txt"], [/* 68 vars */]) = 0 
[pid  8524] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8524, si_status=0, si_utime=0, si_stime=0} --- 
Process 8525 attached [pid > 8525] execve("/bin/cat", ["cat", "testfile.txt"], [/* 68 vars */]) = 0
Hello [pid  8525] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8525, si_status=0, si_utime=0, si_stime=0} --- 
Process 8526 attached [pid > 8526] execve("/bin/rm", ["rm", "testfile.txt"], [/* 68 vars */]) = 0
[pid  8526] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8526, si_status=0, si_utime=0, si_stime=0} ---
+++ exited with 0 +++

Параметры (от strace man):

-f: Трассировка дочерних процессов по мере того, как они создаются отслеживаемыми в настоящее время процессами в результате системных вызовов fork (2), vfork (2) и clone (2). Обратите внимание, что -p PID -fбудут присоединены все потоки PID процесса, если он многопоточный, а не только поток с thread_id = PID.

-e trace=file: Трассировка всех системных вызовов, которые принимают имя файла в качестве аргумента. Вы можете думать об этом как об аббревиатуре, для -e trace=open,stat,chmod,unlink,...которой полезно видеть, на какие файлы ссылается процесс. Кроме того, использование аббревиатуры гарантирует, что вы не забудете случайно включить в список вызов типа lstat.

ОС Linux основана на файлах, и многие команды, выполняемые в Linux, скорее всего, разрешат некоторые изменения в файлах, расположенных на вашем компьютере. Из-за этого, возможно, является лучшим решением для вашей проблемы. Вы можете проверить свои команды на любые изменения в файловой системе перед ее выполнением.

Есть команда 'strace', которая декомпилирует вашу команду по частям ...

Если вы действительно хотите углубиться, вы должны проверить декомпиляторы для сценариев, которые будут выполняться. Другими словами, вы должны проверить интерпретацию ассемблера этой команды. Для Баша есть objdump -d. Linux bin скрипты в основном создаются на Cязыке программирования, поэтому используйте хороший Cдекомпилятор.