LINUX.ORG.RU

Проблемы с перехватом sys_execve()

 , ,


0

3

В общем, пытаюсь перехватить sys_execve(), ядро ломается и все такое. Когда я проверил адреса, то меня кое что слегка удивило. А именно:

Константа __NR_execve в /usr/include/asm-generic/unistd.h равна 221, однако когда я вывожу ее в консоль во время работы модуля - мне указывается значение 59.

Ну и собственно, адрес, на который указывает sys_call_table[__NR_execve], в файле System.map, указывает на stub_execve. Однако судя по тому что написано здесь, это обычный дефайн, и, если я правильно понимаю, что такое дефайн, то у меня возникает закономерный вопрос. Почему адреса разные, если это одна и та же сущность?

Ответ на: комментарий от mix_mix

Можно еще порыться в каких-нибудь интеловских-амдшных мануалах на эту тему

SZT ★★★★★
()
Ответ на: комментарий от mix_mix

По частям же, в два push.

И как ты себе это представляешь?

teststack:     file format elf64-x86-64


Disassembly of section .text:

0000000000400080 <_start>:
  400080:	68 44 33 22 11       	pushq  $0x11223344
  400085:	68 44 33 22 11       	pushq  $0x11223344
...
после двух этих push-ей ожидаемый результат:
(gdb) print/x *((unsigned long long *)$rsp+1)
$1 = 0x11223344
(gdb) print/x *((unsigned long long *)$rsp+0)
$2 = 0x11223344
Оно записывает в стек с выравниванием под 64, старшие 32-битные кусочки оно просто зануляет. Можно конечно в регистр записать 64-битное значение и потом пушнуть, но зачем, если можно через регистр сразу call сделать

SZT ★★★★★
()
Последнее исправление: SZT (всего исправлений: 1)
Ответ на: комментарий от mix_mix

Точно, забыл) Еще раз спасибо.

А вот меня интересует, есть ли какой-то еще способ нахождения таблицы системных вызовов? Чтобы он не зависел от наличия файла System.map и тому подобного?

Просто то что я нашел, ищет адрес в коде обработчика прерывания 0x80, а в 64-битной архитектуре, вроде как 2 таблицы и несколько способов попасть к ним. При чем, как я понял, по умолчанию используется не та, что при прерывании 0x80.

Mizantrop_LoL
() автор топика
Ответ на: комментарий от vasily_pupkin

Нужно запретить запуск процессов из некоторого черного списка с помощью модуля ядра. Linux Security Modules не подходит, т.к. его может не быть (у меня, например, как я понял, нету). Других методов я не нашел.

Mizantrop_LoL
() автор топика
Ответ на: комментарий от Mizantrop_LoL

И как ты собрался определять, что запускаемое приложение это именно то приложение, которое ты не хочешь что бы запускалось? )

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Блочить нужно по названию (путь к бинарнику и его имя). Да, я понимаю что это никакой безопасности не даст, но задание именно такое.

Mizantrop_LoL
() автор топика
Ответ на: комментарий от SZT

Спасибо) Решил использовать поиск с помощью kallsyms_lookup_name(). Раньше не использовал, ибо сказали типа «папка proc может быть не включена при сборке ядра», но тут так подумал, мол как минимум там файл придется создавать, так что папка должна быть.

В общем, спасибо за наводку)

Mizantrop_LoL
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.