Перехват обращений к файлу в ядре Linux.

Можно ли такое реализовать. Нужно создать загружаемый модуль ядра который бы отслеживал запись в определенный файл. Уже неделю в гугле ищу и ничего кроме

Код (Text):

1. /* Source 4.1 */
2.     #include <linux/module.h>
3.     #include <linux/kernel.h>
4.     #include <sys/syscall.h>
5.  
6.     /* Экспортируем таблицу системных вызовов */
7.     extern void *sys_call_table[];
8.  
9.     /* Определим указатель для сохранения оригинально вызова */
10.     int (*orig_mkdir)(const char *path);
11.  
12.     /* Создадим собственный системный вызов. Наш вызов ничего не делает,
13.        просто возвращает нулевое значение */
14.     int own_mkdir(const char *path)
15.     {
16.         return 0;
17.     }
18.  
19.     /* Во время инициализации модуля сохраняем указатель на оригинальный
20.        вызов и производим замену системного вызова */
21.     int init_module(void)
22.     {
23.         orig_mkdir=sys_call_table[SYS_mkdir];
24.         sys_call_table[SYS_mkdir]=own_mkdir;
25.         printk("sys_mkdir replaced\n");
26.         return(0);
27.     }
28.  
29.     /* При выгрузке восстанавливаем оригинальный вызов */
30.  
31.     void cleanup_module(void)
32.     {
33.         sys_call_table[SYS_mkdir]=orig_mkdir;
34.         printk("sys_mkdir moved back\n");
35.     }
36.     /* EOF */

не нашел. Еще можно то же самое но через /dev/kmem но вся проблема в том что у меня в Debian нет kmem (не знаю как в других), а предыдущий код после компиляции и выполнения insmod ругается на неэкспортируемый sys_call_table. Где то вычитал что на современных ядрах таблица системных вызовов не экпортируется. И в этом похоже вся проблема. Может кто-нибудь знает как сейчас это реализовывают. Помогите пожалуйста.

 

https://github.com/fpletz/kernelroll

 

Спасибо. Но если в системе нет System.map файла то как тогда быть. Есть ли какой нибудь универсальный способ перехвата обращений к файлам который работал бы в большинстве систем.

 

В современных ядрах не экспортируется sys_call_table, а также стоит защита на запись в эту область памяти. Код с гитхаба вообще стремный. Учитывать нужно и тот факт, что в 64битной системе возможно будет 2 таблицы сисколов...

 

В современный системах Linux это вообще как нибудь нормально можно реализовать? Чтоб выполнить какие то свои действия прежде чем вызвать оригинальный обработчик. Может какой нибудь драйвер-филтр?

 

Конечно можно, там 100500 способов. Но для этого нужна квалификация, просто так рабочий код никто вам не даст.

 

7mm
Вот обьясните мне, я в линупсах не шарю. Ось опенсурсная полностью, а столь примитивную задачу сложно решить, вдобавок рабочий код не дадут!, зачем же тогда опенсурсность. И как вообще это может работать и что такое "экспортируемый", если есть сурс оО ?

 

Экспортируемость = возможность динамической линковки. С этим символом уже нельзя слинковать модуль, т.к. он не экспортируется и искать его теперь нужно вручную используя, например тот же LDE.

По поводу опенсурсности. Да, код доступен. Но это лишь облегчает процесс разработки, т.к. не тратиться время на реверсинг. Хотя в вашем случае, это не определяющий фактор гыгы.

Автору - смотреть код, разбираться, задавать конкретные вопросы.

 

7mm
Всё же я не понимаю. Ну перекомпилил модуль или что там вы компилите. Использовать экспорт для полностью опенсурсной оси это маразм.

Это я знаю. Там оно тратится на ресерч обфусцированных сурсов

 

Ну представьте, что вы приходите на систему с "чужим" ядром. Т.е. оно есть как данность. Вам нужно, чтобы ваш кодес отработал. По-сути, с этого места, задача точно такая же как и в венде.

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

Кроме этого, экспорты поделены на категории. Например, есть группа GPL-символов и юзать их можно только из GPL модуля ну и т.д.

 

Все эти способы основаны на подмене оригинального адреса в sys_call_table на свой собственный или есть другие способы? Если можно хоть с десяток основных и наиболее правильных подскажите ( хотя бы основные принципы на которых эти способы основаны). Ну я вообщем то рабочий код не прошу, мне хоть общее описание техник с помощью которых это можно сделать правильно и "нестремно".

 

7mm

GPL это general public license?
Если да, то "GPL символы" это идиотизм в терминальной стадии)

 

linkmaze
Можно подменить адрес в sys_call_table, можно похукать необходимые функции на лету. Кстати, для последнего способа можно использовать штатный механизм kprobes (jprobes). Первоочередная задача, которую вам нужно решить - определение адреса символов в динамике, т.е. будучи загруженным. Как вариант, можно из ядра читать файл /proc/kallsyms. Погуглите на эту тему, есть семплы как это сделать с использованием экспортируемой функции filp_open.

K10
Идиотизм, не идиотизм - это данность, присущая всему opensource сообществу. Там заморачиваются с лицензионной чистотой, знаете ли. Но кого это останавливает?

 

7mm
Это же epic fail, под закрытую ось кодят такое на коленке, а имея конпилябельные сурсы это проблема!?

 

Инде, это не проблема Где вы увидели проблему?...

 

7mm
Ну хз, вон кто то говорил что привад, да и вообще раз топик есть, значит есть проблема

 

Т.е. это jmp внедрить на свой код в первые байты целевой функции.

 

У меня в /proc/kallsyms нет строки с sys_call_table или в нем нужно искать sys_read, sys_write, sys_open.
Если так то sys_read, sys_write, sys_open этих функций будет достаточно или есть какие-либо еще отвечающие за работу с файлами.

 

linkmaze
Да, можно хукать через jmp. Через kallsyms можно что-то найти, а чего-то там не будет. Чтобы понять, что хукать, нужно смотреть в код. Это можно сделать, например, тут http://lxr.linux.no/linux+v3.2.1/fs/open.c. Как видно, для open существует разновидность -- openat. Но так или иначе, всё сводиться к do_sys_open. Её и нужно хукать Для read/write смотрите файл read_write.c.

Если соберётесь модифицировать таблицу системных вызовов, то её поиск можно осуществить исходя из обработчиков системных сервисов. Для X86_32 их будет всего 2 -- int $80 (system_call) и sysenter (ia32_sysenter_target). Для X86_64 их может быть до 4х -- int $80 (ia32_syscall), sysenter (ia32_sysenter_target), syscall в режиме 32e (ia32_cstar_target) и нативный syscall (system_call).

После того, как найдёте адреса этих символов, можно использовать LDE для поиска характерной инструкции вызова диспетчера системных вызовов:

Код (Text):

1.         call *sys_call_table(,%eax,4) для X86_32

Код (Text):

1.         call *sys_call_table(,%rax,8) для X86_64

 

Так это наварное не мене стремно чем код с гитхаба (или там все проблемы сводятся к GPF_DISABLE GPF_ENABLE).
Т.е слежку за файлами в Linux можно осуществить только через перехват системных вызовов (подменой адреса в sys_call_tables) или непосредственным хуком функций для работы с файлами. Других способов так сказать более легальных я так понимаю нет?