Module

Для Linux? В linux/arch/.../kernel/entry.S или в GLibc в sysdeps.

А зачем они нужны?

А как по другому переопределить системный вызов?

Может я как то неясно выражаюсь - не так давно этим занимаюсь. Допустим хочу переопределить вызов open() - пишу свою функция типа sys_open(const char *filename, int flags, int mode), и затем переопредяю на нее в таблице вызовов. А какой прототип будет например у execve() ?

>А какой прототип будет например у execve() ?


Таблица системных вызов (с именами) есть в entry.S. Открывай, листай, потом ищи по исходникам ядра. Твой execve живет в linux/fs/...


Но я бы не рекомендовал ковырять таблицу системных вызовов.

А чем это чревато? Не я конечно понимаю что можно сделать систему неработоспособной, или есть какие то другие причины?

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

>А чем это чревато? Не я конечно понимаю что можно сделать систему неработоспособной, или есть какие то другие причины?

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

Если нужно переопределить поведение программы, то нужно это делать цивилизованно (как artsdsp, runsocks и др.) - через LD_PRELOAD. Единственное, что неудобно - то, что в glibc не предусмотрена глобальная настройка LD_PRELOAD.

2 roy:

для чего вам нужно перехватить sys_open? возможно, вам
достаточно LSM. если для тестирования/хакинга, то, может
вам стоит посмотреть на kprobes.

модифицировать sys_call_table не очень хорошо. представьте,
вы перехватываете sys_open, потом другой модуль делает
то же самое, потом ваш модуль выгружается, потом выгружается
другой модуль - крах.

Murr:
> На месте Торвальдса я бы даже снимал со страниц массива
> бит возможности записи, чтобы горе хакеры туда не лезли.

самое интересное, что Торвальдс с тобой согласен. бит
записи не снимается, это было бы не так просто, т.к.
страницы по 4Mb, но sys_call_table не экспортируется
начиная с 2.6.

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

как минимум, это полезно для тестирования всякого рода.

idle:

>самое интересное, что Торвальдс с тобой согласен. бит
>записи не снимается, это было бы не так просто, т.к.
>страницы по 4Mb, но sys_call_table не экспортируется
>начиная с 2.6.

4Mb - это нормально.
Нужно весь образ ядра отобразить в r/o (за исключением bss).
Я думаю выровнять bss по 4 Мб - не проблема.

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

Мое мнение примерно такое.
Ядро у нас open-source, но это не должно вводить в заблуждение.
Есть в нем довольно статичные интерфейсы (типа блокировок или интерфейсов VFS или memory allocators), а есть внутренняя кухня ядра.
Вот системные вызовы - это как раз внутренняя кухня ядра. Начиная с 2.6 ядро даже экспортирует метод входа в себя для Glibc (а-ля DSO), чтобы последнее не заботилось о том, как ему входить в ядро.

Если максимально усложнить жизнь тому, кто туда хочет залезть, то это может заставить его дважды подумать правильно ли он поступает.

> Я думаю выровнять bss по 4 Мб - не проблема.

как это? мы ведь можем потерять до 4Mb памяти при этом?
если, скажем, у нас .rodata + .text + .other_ro_sections
== 4Mb + 1 byte.

по этой причине не все данные в свежих 2.6 ядрах защищены
_PAGE_NX битом.

> Вот системные вызовы - это как раз внутренняя кухня ядра.

да я не спорю. но большая часть настроек в /proc/sys
интересна только для того, кто знает что делает, их
же не отменяют по этой причине?

но тут уж спорить не о чем, вопрос вкуса.

idle против Murr + Torvalds!

эх, работать-то как не хочется...

опять забыл падписацца

Я экспериментирую. Правда как то не так. Просто хочется поизучать ядро, вот и залез в эту таблицу. Идея была такова: например переопределить вызов execve, и записывать в лог имя юзера и прогу котрую он запускает. Может конечно извратно покажется, но хз. А как без изменения таблицы вызовов и с помощья именно ядра это сделать? На счет того что разные мудули преопределят одно и то же читал, но я пишу для себя, поэтому это маловероятно я думаю.

idle:
>как это? мы ведь можем потерять до 4Mb памяти при этом?
>если, скажем, у нас .rodata + .text + .other_ro_sections
>== 4Mb + 1 byte.

Ну 4 Мб - это вырожденный случай. В среднем все же 2.
К тому же "потерянные" страницы можно, IMHO, использовать, отобразив их в отдельный виртуальный node (по типу удаленной памяти).

>да я не спорю. но большая часть настроек в /proc/sys
>интересна только для того, кто знает что делает, их
>же не отменяют по этой причине?

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

>но тут уж спорить не о чем, вопрос вкуса.
Безусловно. :)

>эх, работать-то как не хочется...
Ну так не работай. Я не работаю, когда не хочется. Другое дело, что нужно иметь внутренний огонек, который может побудить весь вечер/ночь или выходные колупаться, чтобы продукт не страдал.

Ты, кстати, в какой области работаешь?

>Идея была такова: например переопределить вызов execve, и записывать в лог имя юзера и прогу котрую он запускает.

Сие вроде называется BSD process accounting и работало оно еще на древней 4.3BSD (вероятно, даже еще раньше).

Но хочется то самому такое написать ;)

Murr:

> > эх, работать-то как не хочется...
>
> Я не работаю, когда не хочется.

да я бы тогда вообще никогда не работал!

> Ты, кстати, в какой области работаешь?

да трудно сказать. управление железякой, которая наша
фирма делает. немного в kernel, немного perl.

работа непыльная, люди хорошие, только что-то надоело.

поэтому приходится неделми на форумы не ходить, чтобы
заставить себя сделать хоть что-нибудь :)