Проверьте, действительно ли консольное приложение завершено.

Схема блокировки, используемая для операций с каталогом, основана на двух типах блокировок - на каждый индекс (-> i_mutex) и на файловую систему { {1}} (-> s_vfs_rename_mutex).

При использовании i_mutex для нескольких объектов, не относящихся к каталогу, мы всегда устанавливаем блокировки по порядку, увеличивая адрес. Мы будем вызывать этот порядок "указателя inode" в следующем виде.

Для наших целей все операции делятся на 5 классов:

1) доступ для чтения. Правила блокировки: вызывающий абонент блокирует каталог, к которому мы обращаемся.

2) создание объекта. Правила блокировки: такие же, как указано выше.

3) удаление объекта. Правила блокировки: вызывающий блокирует родителя, находит жертву, блокирует жертву и вызывает метод.

4) rename (), то есть перекрестный каталог , а не . Правила блокировки: вызывающая сторона блокирует родителя и находит источник и цель. Если цель уже существует, заблокируйте ее. Если источник не является каталогом, заблокируйте его. Если это означает, что нам нужно заблокировать оба, заблокируйте их в порядке указателя inode.

5) создание ссылки. Правила блокировки: * заблокировать родителя * проверить, что источник не является каталогом * заблокировать источник * вызвать метод.

6) перекрестное переименование каталогов. Самый хитрый из всей связки. Правила блокировки : * заблокировать файловую систему * заблокировать родителей в порядке «сначала предки». * найти источник и цель. * если старый родитель равен или является потомком цели сбой с -ENOTEMPTY *, если новый родитель равен или является потомком источника сбой с -ELOOP {{1 }} * Если цель существует, заблокируйте ее. Если источник не является каталогом, заблокируйте его . В случае, если это означает, что нам нужно заблокировать и источник, и цель, сделайте это в порядке указателя inode. * вызовите метод.

Вы можете написать сценарий, который может проверять блокировку каталога, используя некоторую информацию из 6 операций над dir.

5
13.01.2017, 05:00
4 ответа

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

$ my_secret_func() { echo "Still alive"; }
$ ~/Downloaded/dubious_program
$ my_secret_func
Still alive

Если dubious_program является вредоносным, он может легко обмануть вас, передав ваш ввод исходной оболочке и позволив ей отреагировать. В общем, небезопасный исполняемый файл имеет множество способов установить кейлоггер под вашей личностью ( и делать много других вредоносных вещей), например, саму установку в ваш ~ / .bashrc . Он мог бы сделать это, даже если бы не было видимых эффектов - на самом деле, большинство вредоносных программ стараются не оказывать никакого немедленного видимого эффекта, чтобы минимизировать риск обнаружения.

Итак, если вы не уверены, что то, что вы выполняете, безопасно, либо выполните его с пользователем никто в песочнице, либо не выполняйте его вообще.

8
27.01.2020, 20:31

Как проверить, вернулись ли вы в оболочку

Сравните PID оболочки до и после выполнения команды (один и тот же PID означает ту же оболочку):

$ echo $$
6215
$ bash --posix
bash-4.3$ echo $$
10230
bash-4.3$ exit
$ echo $$
6215

В приведенной выше демонстрации вы можете увидеть, как я запускаю приложение, в этом случае другой bash в режиме POSIX. По возвращении мы проверяем, что PID используемой оболочки совпадает, поэтому мы можем предположить, что это фактическая оболочка. Это, конечно, можно автоматизировать, добавив $$ в приглашение оболочки:

$ PS1="[$$] $PS1 "
[6215] $

Варианты темы могут быть выполнены с помощью проверки sha256sum (или любой другой контрольной суммы, например ] md5 ) до и после. Ша-суммы, если вы не знаете, часто используются для проверки целостности файлов, особенно для загрузок и изображений iso . В демонстрации ниже мы используем файл / proc / / exe , который является символической ссылкой на реальный двоичный файл (в данном случае это будет моя оболочка mksh ). Таким образом мы можем убедиться, что исполняемый файл, который мы запускаем, тот же самый.

[12107][xieerqi][21:34]:
$ sha256sum /proc/$$/exe
70a16895186ddfac12343e816f05783cf60092c0980fc20c2ae4bc53b48f28e6  /proc/12107/exe

[12107][xieerqi][21:34]:
$ bash --posix
bash-4.3$ sha256sum /proc/$$/exe
c2615a71ff5c004e51aef248103a2950c25715f5eb8130837695770e1d78ecfa  /proc/12434/exe
bash-4.3$ exit

[12107][xieerqi][21:35]:
$ sha256sum /proc/$$/exe
70a16895186ddfac12343e816f05783cf60092c0980fc20c2ae4bc53b48f28e6  /proc/12107/exe

Возврат в оболочку не является гарантией безопасности

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

Что касается самих командных интерпретаторов, то процесс можно запускать в фоновом режиме. Например, сценарии оболочки используют амперсанд, например, так command & для запуска чего-либо в фоновом режиме .Я не уверен, что фоновый процесс все еще может читать ключи, но тот факт, что оболочка завершает работу, не является гарантией выхода из приложения. В небольшой демонстрации ниже вы можете увидеть, как функция запускается в фоновом режиме, сценарий, по-видимому, завершается, но функция по-прежнему записывает в out.txt каждую секунду.

[10754][xieerqi][21:12]:
$ cat launch_background_app.sh

#!/bin/bash

run_in_background()
{
    while true;
    do
       date +%s > out.txt
       sleep 1
    done
}

run_in_background &

[10754][xieerqi][21:12]:
$ ./launch_background_app.sh

[10754][xieerqi][21:12]:
$ cat out.txt
1484280777

[10754][xieerqi][21:12]:
$ cat out.txt
1484280778

[10754][xieerqi][21:12]:
$ cat out.txt
1484280779

ПРИМЕЧАНИЕ ДЛЯ РЕДАКТОРОВ : пожалуйста, не удаляйте приглашение из моего примера - оно предназначено для демонстрационных целей, чтобы показать, что PID оболочки остается прежним.

P.S: безопасность начинается с установки доверенного приложения в первую очередь, поэтому рассмотрите возможность обеспечения целостности приложения перед тем, как его в первую очередь использовать.

6
27.01.2020, 20:31
 suspect-command; echo I am thinking of the number 43987

После выхода команды будет запущено эхо. Вы должны увидеть результат в строке над командной строкой.

4
27.01.2020, 20:31

Кейлоггер не будет пытаться подделать приглашение оболочки, он почти наверняка оставит фоновый процесс, который отслеживает /dev/input или что-то подобное (он также попытается скрыть себя в списке процессов). Вы определенно смотрите на проблему с неправильной стороны.

Обычным способом запуска ненадежных двоичных файлов является создание виртуальной машины и запуск их там. Даже это не дает 100% безопасности, но часто считается достаточно безопасным для практического использования (конечно, вы не будете запускать виртуальные машины с недоверенным кодом на рабочем сервере или внутри защищенной сети в банке).

5
27.01.2020, 20:31

Теги

Похожие вопросы