Проверка бинарных файлов команд перед выполнением
Существуют ли какие-либо методы для проверки того, что вы на самом деле выполняете из сценария bash?
Скажем, ваш скрипт bash вызывает несколько команд (например: tar
, mail
, scp
, mysqldump
), и вы готовы убедиться, что tar
является фактическим, реальным tar
, который определяется пользователем root
являющимся владельцем файла и родительского каталога и только с правами на запись, а не с некоторыми /tmp/surprise/tar
с www-data
или apache2
являющимися владельцем.
- Почему корневая оболочка по умолчанию настроена по-другому с обычной оболочкой обычного обычного пользователя?
- Как удалить скрытую папку?
- Возможность легко переключаться между каталогами в разных областях
- Замена шаблона после n-го совпадения найдена в каждой строке?
- Создать имя каталога на основе других других каталогов
Конечно, я знаю о PATH
и среде, мне любопытно узнать, можно ли это дополнительно проверить из сценария запуска bash, и если да, то как именно?
Пример: (псевдокод)
tarfile=$(which tar) isroot=$(ls -l "$tarfile") | grep "root root" #and so on...
- Почему расширение оболочки на popd не удаляет каталог из стека?
- Bash - Как перебирать подкаталоги и извлекать файлы
- индикатор выполнения, чтобы узнать, сколько выполнено выход скрипта оболочки
- синтаксическая ошибка рядом с неожиданным токеном `('ИЛИ нет правильного выполнения
- Общие обозначения и стандарты флагов для сценариев и функций оболочки
- Как рекурсивно добавлять нули в имя файла
- Определите файлы / каталоги, измененные в результате выполнения команды
- Перечислять дубликаты имен файлов в листинге?
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