Как стать автором
Обновить

Комментарии 12

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

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

P.S: автору спасибо, на хабре так редко мелькают статьи по разработке в Kernelspace, и им уделяется так мало внимания…
Статья просто бомба! Действительно, крайне жаль, что на хабре не так много людей, которым интересная kernelspace-разработка, да еще и в Linux-ядре.
Я бы не сказал что слишком мало) Проблема в том что писать про ядро не так просто (не повторить статью из lwn), да и понимает о чем конкретно идёт речь небольшой процент читающих.
И по защите — в последних андроид ядрах в ядре выключены модули по умолчанию (метод указанный ниже).
Собирайте ядро с выключенной опцией CONFIG_MODULES и живите спокойно :)
От рута всё равно не спасёт. Он откроет /dev/mem и запишет свой код в kernel space. Просто это сложнее, чем скомпилить модуль.
/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  */
Любопытно, linux движется в ту же сторону, что и windows.
К примеру, на Server 2003 локальный админ через \Device\PhysicalMemory мог что-то поделать, а также открыть процесс чужой терминальной сессии и сделать туда WriteProcessMemory. В 2008R2 ничего из этого локальный админ сделать не может.
Ну логичный тренд, всё-таки. Зачем админу доступ к чужим процессам?
Ну так он же царьибох на компе, как жеж ;)

Вообще тренд стал в линуксе очень явным, когда стал маячить Secure Boot. Вот тут они хорошо подсуетились, все лазейки позакрывали, так что у рута в этом случае реально нет шансов завести неподписанный код в режиме ядра.
SELinux всегда ограничивал рута и нет в этом ничего плохого :) Другое дело на сколько такая защита всё-таки эффективна, ведь в конечном счёте переполнению буфера в ядре не важно под кем оно происходит…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации