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

Существуют ли какие-либо методы для проверки того, что вы на самом деле выполняете из сценария bash?

Скажем, ваш скрипт 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... 

6 Solutions collect form web for “Проверка бинарных файлов команд перед выполнением”

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

  • Блок условного исполнения с || и круглые скобки
  • Запустите bash subshell с командами от имени другого пользователя и не возвращайтесь в родительскую оболочку
  • Поддерживают ли оболочки рекурсию?
  • Посмотрите, есть ли в папке несколько файлов с определенными расширениями
  • Получить номер строки в сценарии оболочки Bourne
  • chown все файлы на основе шаблона имени файла в текущем каталоге
  • Чтение цели символической ссылки и увеличение целевой
  • Печать пространства между строками
  • Как показать конкретные строки из определенных столбцов файла
  • Как войти в систему как root из Bash и делать что-то
  • Копирование / резервное копирование всех файлов, содержащих файлы, соответствующие регулярному выражению
  • Linux и Unix - лучшая ОС в мире.