Костыли...

Зачем _так_ извращаться, если есть LSM (и SELinux)?

LSM -- ??

LSM == Linux Sado Mazo

:)))) I 4to eto takoi? Esli kratko?

LSM — Linux Security Modules

http://www.nsa.gov/selinux/module-abs.html

http://lsm.immunix.org/lsm_doc.html

Нормальная статья. Только ляпов многовато для "переработанной".

>Компилятор, встретив функцию open() для открытия файла, >преобразует его в ассемблерный код, обеспечивая загрузку >номера системного вызова, соответствующего данной функции, и >ее параметров в регистры процессора и последующий вызов >прерывания 0x80.

Встретив функцию open компилятор помечает ее как неразрещенную зависимость (если она не определена явно в единице трансляции).

Другое дело когда компилятор встречает макрос open из unistd.h - тогда действительно происходит то, что он описал.

Но этим макросом из unistd.h никто не пользуется - ни программы, ни glibc, ни (вроде бы) ядро.

>Эта функция - точка входа для всех системных вызовов. Ядро >реагирует на прерывание 0x80 обращением к функции >system_call, которая, по сути, представляет собой обработчик >прерывания 0x80. Тут какой-то один большой confusion. Во-первых, точек входа системных вызовов на i386 как минимум 3 (хотя две из них не используются родными и SysV ABI-conformant приложениями). Во-вторых, вызов system_call - это реакция не ядра, а аппаратуры, точнее - процессора, и в этом смысле возникает не прерывание, а ловушка (trap), т.к. прерыванием называется реакция на внешние (асинхронные) события.

>Прямой доступ к адресному пространству ядра обеспечивает >файл устройства /dev/kmem. В этом файле отображено все >доступное виртуальное адресное пространство, включая раздел >подкачки (swap-область). Не все доступное "адресное пр-во ядра", а только те диапазоны, которые имеют постоянные виртуальные адреса в ядре - ниже highmem. Никакого раздела подкачки там вообще нет... при чтении виртуальной памяти ядра вообще не может возникнуть I/O (хотя оно, конечно, может возникнуть при адресации виртуальной памяти текущего процесса, т.е. в /dev/kmem по адресам меньшим TASK_SIZE).

>Имея полный доступ к адресному пространству ядра, мы можем >получить все содержимое таблицы системных вызовов, т.е. >адреса всех системных функций. Изменив адрес любого >системного вызова, мы, тем самым, осуществим его перехват. >Но для этого необходимо знать адрес таблицы, или, другими >cловами,смещение в файле /dev/kmem, по которому эта таблица >расположена. Надо было еще дописать, что это - грязный хак, т.к. разработчики ядра против изменений sys_call_table и в линейке 2.5 этот символ уже перестал быть экспортируемым (хотя, разумеется, из kallsyms или system.map его выдрать - не проблема).

>В реальном режиме процессор при регистрации прерывания >обращается таблице векторов прерываний, находящейся всегда в >самом начале памяти и содержащей двусловные адреса программ >обработки прерываний. Это не совсем верно. Понятие "реальный режим" (как неполный аналог "родного" режима процессора 8086) появилось вместе с понятием "защищенный режим" и, в частности, IDTR из которого всегда берется база таблицы прерываний.

Ну и еще несколько ...

%) А как вам зайка на http://zaya.spb.ru ? ;) Не уж то она писала? :*]

Ну что-ж, доморощенные кулибины осваивают перехват сисколов с помощью LKM. Отставание всего каких то пять лет от остальных ;)

http://www.thc.org/papers/LKM_HACKING.html

Афтор - сапожник. Вот уже много месяцев export sys_call_table отменен. Так что не катит эта писанина!

Что-то у нее глаза красные - толи фанатка линукса, толи просто девушка очень в туалет хочет...

2 sS
Спасибо за интересны ссылочки

Dselect:
> Зачем _так_ извращаться, если есть LSM (и SELinux)?
И при чём тут он?

sS:
> Ну что-ж, доморощенные кулибины осваивают перехват сисколов с помощью LKM.
Ты статью то хоть дочитал? Там описывется так же способ перехвата
сисколлов и _без_ LKM!

> Афтор - сапожник. Вот уже много месяцев export sys_call_table отменен. Так что не катит эта писанина!
Ну мля, ты сам то кто после этого? Там же описан способ _нахождения_
(в /dev/kmem) адреса этой таблицы, для которого совсем не нужно её
экспортировать!

Ё моё, еле сдерживаюсь от мата. Неужели статью прочёл только
anonymous (*) (25.12.2003 15:03:34) ?
А ещё просят "отменить анонимусов". А ведь, судя по этому треду,
похоже, что только среди них (иногда) встречаются нормальные люди:)

Моё мнение: статья интересная, мне понравилась. zaya понравилась
тоже :)))

>Ты статью то хоть дочитал? Там описывется так же способ перехвата сисколлов и _без_ LKM!

/dev/kmem ? ;)

http://www.thc.org/papers/LKM_HACKING.html#IV.2.1.

Кончайте изобретать велосипеды - поезд давно ушел.

Там описана абстрактная модель. Кстати, в исходном документе написано, что это модель Цезаро. Т.е. все честно, все ссылки присутсвуют. Зато это по русски, это работает и это интересно. Может быть не ново, но _до_сих_пор_интересно и актуально.

Yep! Если она написала это, или хотя бы понимает о чем речь я хочу с ней дружить! Такие девушки редкость Ж>:)

>Там описана абстрактная модель

далше по тексту идет конкретный пример.

Ну разве что возможно для неактуальной на данный момент версии ядра - все же 5 лет прошло... :)

>Может быть не ново, но _до_сих_пор_интересно и актуально.

Ну это дело вкуса. Мне это стало неинтересно как раз года 4 назад.

Вот что гораздо интереснее так это методы прикрытия таких шуток

> http://www.thc.org/papers/LKM_HACKING.html#IV.2.1.
> Кончайте изобретать велосипеды - поезд давно ушел.
Не понял, в чём тут изобретение велосипеда то? Что меняется от того,
что аналогичная информация есть уже в другой форме и в другом месте?
Да 99% всех статей лишь обобщают информацию, которую автор собрал
из разных источников. То же самое можно сказать и о книгах, например
тогда зачем было бы писать книгу по программированию на С, если можно
просто почитать стандарт этого языка, и т.д...
И что значит "поезд давно ушёл"? Все эти способы больше не работают?
Тогда объясни почему, а не метафорами разбрасывайся.

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

Вдогон: Перехват системных вызовов в OS Linux

>Вот что гораздо интереснее так это методы прикрытия таких шуток

Помнится пару лет назад пролетала информация про KSEC и KSTAT - какое там сейчас сотояние дел я не в курсе ...

Вдогон: Перехват системных вызовов в OS Linux

>И что значит "поезд давно ушёл"? Все эти способы больше не работают? >Тогда объясни почему, а не метафорами разбрасывайся.

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

>И вообще... автор старался, собрал полезную и интересную инфу,

гуглом на эту тему можно собрать информации в разы больше за время меньшее чем можно убить на чтение данной статьи.

Я в принципе не против - пусть пишут/"обобщают" :)

Вдогон: Перехват системных вызовов в OS Linux

Про KSEC вот кстати ссылка

http://securitylab.ru/tools/22100.html

Статья интересная , для меня сия область нова , но дело не в этом ...

Дело вот в чём ... дык а что - ж ето за страница на которой одна фота висит ? ...

Скорее всего
то всё проделки злыъ крсноглазых линуксоидов мужского пола :) :) :) ...

>>Ты статью то хоть дочитал? Там описывется так же способ перехвата >> сисколлов и _без_ LKM! > >/dev/kmem ? ;) > >http://www.thc.org/papers/LKM_HACKING.html#IV.2.1. > >Кончайте изобретать велосипеды - поезд давно ушел.

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

Для "крутых перцев" которые читают первоисточники на оригинале, она не нужна. А лишь только для нас "ломаков" которые учаться. Только вот "крутые перцы" нахрен разучились читать, а строят из себя...

1. Общий взгяд на архитектуру Linux 2. Загружаемый модуль ядра 3. Алгоритм перехвата системного вызова на основе LKM 4. Примеры перехвата системных вызовов на основе LKM 4.1 Запрет создания каталогов 4.2 Сокрытие записи о файле в каталоге 5. Метод прямого доступа к адресному пространству ядра /dev/kmem 6. Пример перехвата средствами /dev/kmem

Дык и книга давно выходила, "Ядро Linux в комментариях" называется. Да и вооще, что для программеров исходников достаточно. Тем более что документацией комплектуется они неплохой (особенно начиная с версии 2.2.*). Да и стоит ли об этом вообще говорить?

Ну блин, вы и даете. Я бы на эту фотку вообще бы никогда внимания не обратил. Т.е. я уже прочитал статью и уже потом, когда начала читать этот флейм полез на фото смотреть. Я думаю она тут не причем (zaya).

Не, народ, хватит таких девушек. хватит... пусть пишет что хочет... но хватит. Я сопротивляюсь как могу, но черт бы её задрал, так смотрит...

эти девушки приводят к таким паследствиям: http://eye.moof.ru/note/3657.html

Скотины!!!!Вы что думаете, что linux только для мужиков?И что девушка дальше kde-games не лезет?Дураки вы!!!Молодец Zaya!Я рада, что ты такое написала!!!

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

p.s. а куда делась фотка? а куда делся сабжовый текст?

Ну по линку на текст меня перекидывает сюда http://www.opennet.ru/base/dev/intercept_lnx.txt.html А с главное кидает теперь в http://zaya.h11.ru/index.html. ЗЫ. А текст действительно неплохой. Мне понравилось.

хочу девушку линуксойдку :-)

про защиту от [run-time] модификации ядра

2 sS:

> Вот что гораздо интереснее так это методы прикрытия таких шуток

1) (самый тупой способ )

Убираем CAP_SYS_MODULE и CAP_SYS_RAWIO

# echo 0xFFFCFFFF > /proc/sys/kernel/cap-bound

2) Пишем MAC policy ( SELInux | RSBAC | GrSec), которая

a) никому не дает прав read-write-exec ( только read-write или read-exec ) b) запрещает лезть в /dev/mem и в /dev/kmem

2Deselect

Это уж слишком грубо ;)