Простая маскировка модуля ядра Linux с применением DKOM

[lolipop]

Как же страшно жить!

[weirded]

Было бы интересно увидеть патчик, позволяющий запретить подобные хаки.

Хотя, чего это я, приеду домой, вчитаюсь повнимательнее и попробую сам сделать :)

P.S: автору спасибо, на хабре так редко мелькают статьи по разработке в Kernelspace, и им уделяется так мало внимания…

[ValdikSS]

Статья просто бомба! Действительно, крайне жаль, что на хабре не так много людей, которым интересная kernelspace-разработка, да еще и в Linux-ядре.

[Propheta13]

Я бы не сказал что слишком мало) Проблема в том что писать про ядро не так просто (не повторить статью из lwn), да и понимает о чем конкретно идёт речь небольшой процент читающих.
И по защите — в последних андроид ядрах в ядре выключены модули по умолчанию (метод указанный ниже).

[milabs]

Собирайте ядро с выключенной опцией CONFIG_MODULES и живите спокойно :)

[qw1]

От рута всё равно не спасёт. Он откроет /dev/mem и запишет свой код в kernel space. Просто это сложнее, чем скомпилить модуль.

[milabs]

/dev/mem давно уже ограничен и нельзя просто так взять и записать в произвольный адрес памяти:

314 /*
315  * devmem_is_allowed() checks to see if /dev/mem access to a certain address
316  * is valid. The argument is a physical page number.
317  *
318  *
319  * On x86, access has to be given to the first megabyte of ram because that area
320  * contains bios code and data regions used by X and dosemu and similar apps.
321  * Access has to be given to non-kernel-ram areas as well, these contain the PCI
322  * mmio resources as well as potential bios/acpi data regions.
323  */

[qw1]

Любопытно, linux движется в ту же сторону, что и windows.
К примеру, на Server 2003 локальный админ через \Device\PhysicalMemory мог что-то поделать, а также открыть процесс чужой терминальной сессии и сделать туда WriteProcessMemory. В 2008R2 ничего из этого локальный админ сделать не может.

[milabs]

Ну логичный тренд, всё-таки. Зачем админу доступ к чужим процессам?

[merlin-vrn]

Ну так он же царьибох на компе, как жеж ;)

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

[milabs]

SELinux всегда ограничивал рута и нет в этом ничего плохого :) Другое дело на сколько такая защита всё-таки эффективна, ведь в конечном счёте переполнению буфера в ядре не важно под кем оно происходит…

[milabs]

.