Визначення бінарних команд перед виконанням

Чи є методи перевірити, що ви насправді виконуєте з 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вам скаже, що це "an" 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 +++

Параметри (від людини зі страйком):

-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декомпілятор.