Может я как то неясно выражаюсь - не так давно этим занимаюсь. Допустим хочу переопределить вызов open() - пишу свою функция типа sys_open(const char *filename, int flags, int mode), и затем переопредяю на нее в таблице вызовов. А какой прототип будет например у execve() ?
А что можно почитать по этой теме? А то в гугле много всего находится, аж глаза разбегаются :)
Кокретно интересует 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.
а я вот не согласен с вами обоими. у человека, который
может написать и загрузить модуль все равно остается
достаточно способов чтобы поломать систему, зачем отнимать
возможность поиграться с таблицей вызовов?
как минимум, это полезно для тестирования всякого рода.
>самое интересное, что Торвальдс с тобой согласен. бит
>записи не снимается, это было бы не так просто, т.к.
>страницы по 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 могут меняться только в определенных границах (заранее определенных), причем эти границы определяются так, чтобы ядро могло нормально с ними работать (т.е. если ядро допускает изменение параметра, то оно обязано с ним уметь работать), а у товарища на лицо злой хак. :)
>но тут уж спорить не о чем, вопрос вкуса.
Безусловно. :)
>эх, работать-то как не хочется...
Ну так не работай. Я не работаю, когда не хочется. Другое дело, что нужно иметь внутренний огонек, который может побудить весь вечер/ночь или выходные колупаться, чтобы продукт не страдал.
Murr:
> > эх, работать-то как не хочется...
>
> Я не работаю, когда не хочется.
да я бы тогда вообще никогда не работал!
> Ты, кстати, в какой области работаешь?
да трудно сказать. управление железякой, которая наша
фирма делает. немного в kernel, немного perl.
работа непыльная, люди хорошие, только что-то надоело.
поэтому приходится неделми на форумы не ходить, чтобы
заставить себя сделать хоть что-нибудь :)