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

Вместо проверки двоичных файлов, которые вы собираетесь выполнить, вы можете выполнить правильные двоичные файлы с самого начала. Например, если вы хотите убедиться, что вы не собираетесь запускать /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 . В отличие от команды, которая только выполняет поиск в вашем 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 с thread_id = PID.

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

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

Существует команда 'strace', которая декомпилирует вашу команду по частям …

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