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

Потому что там нельзя загружать неподписанные модули.

Или вообще функционал загрузки модуля может быть отключен.

Вообще, учитывая что мы предполагаем наличие root доступа, дыра в безопасности уже есть. Есть ли какие-нибудь куски кода в ядре, которые можно было бы вызвать из юзерспейса и переписать таким образом какой-нибудь кусок исполняемого кода в самом ядре? А если я например смонтирую swap раздел и во время работы системы со swap-разделом начну его менять как файл? А если раздел не swap а какой-нибудь файловой системы?

Ну так возьми, и подпиши.

ССЗБ. Зачем отключать модули, если они нужны? Что за изврат?

А если я например смонтирую swap раздел и во время работы системы со swap-разделом начну его менять как файл?

То у тебя скорее-всего тупо все покрешится. Алсо, память ядра не свапится никогда. Вообще.

А если раздел не swap а какой-нибудь файловой системы?

Поломаешь ФС своими кривыми руками так, что fsck уже не спасет.

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

Нет.

А это не я их отключал, а производитель быдлодевайса

Нет ключа

Алсо, память ядра не свапится никогда. Вообще.

А если флагом GFP_USER?

сказали же не свопится, хакир. ну не твое это, оставь :)

Ну так запилити тикет производителю, чтобы он пофиксил? Или это китайщина какая без техподдержки? Тогда опять-таки ССЗБ - скупой платит дважды.

Производитель не предоставил? Или вы девайс на ибее купили? В любом случае, смотри мой предыдущий пост про скупость.

Нет. Память ядра никогда не своппится.

«Посоны, как взломать Linux?!!11»

Отключение-подписывание модулей ядра сделано специально, чтобы не допустить выполнение проивольного кода уровня ядра на девайсе. С чего они должны мне что-то там фиксить и отправлять ключи для подписи? Может мне еще в apple обратиться чтобы они мне джейлбрейк к айпаду выслали?

ИМХО - только страдать. Что за девайс-то?

чтобы не допустить выполнение проивольного кода уровня ядра

И ты думаешь, что в ядре не сделали тоже самое, и разрешили коду из userspace просто так срать в kerlenspace. Лiл.

С чего они должны мне что-то там фиксить и отправлять ключи для подписи?

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

Секрет. Может когда (если) похакаю - сообщу

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

Чтобы хакнуть и пилить модули ядра.

Кстати надо еще проверить, там оперативка расположена внутри SOC-а или на отдельной микросхемке

Байтики вручную хакерить будешь?)

Угу, спаяю на микроконтроллере переходник для оперативки и пропатчу им байтики во время работы

/dev/mem /dev/kmem и /proc/kcore не работают

Почему?

PS если ведро старое то там стопудово куча локальных дыр. Парси списки уязвимостей.

А нафига ты тогда взял такой девайс, где неподписанные модули не поставишь? Что за BDSM? Ты не из ВНИИНС, случаем - тамошние разработчики обычно любят такое.

Ты это серьезно? Ты хоть знаешь, какие байтики тебе патчить надо будет? С вероятностью 0.(9) ты просто девайс/ядро заставишь о бытие задуматься.

Если есть root доступ, то можно rm -rf /*

Потому что этот функционал в ядре отключим

Что мне дадут локальные дыры, если предполагаем root у меня уже есть? Через них можно код ядра в оперативке запатчить, чтобы можно было делать insmod?

И какой будет толк от rm -rf /* ? Брикнуть девайс?

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

Нет. Ты говоришь про дыру в безопасности, если есть root. Если есть root, то враг уже внутри.

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

Через них можно код ядра в оперативке запатчить, чтобы можно было делать insmod?

Да, если найдёшь подходящую дыру и подходящий эксплоит. Но, скорее всего, потребуется написать свой шелл-код.

что можно выпаять и заменить

Это хорошо. Обычно проверятор бутлоадера сидит внутри SoC.
Тогда и правда стоит поискать дырки в ядре, чтобы была возможность исполнить код на кернел сайде. Такие, мне кажется, существуют в природе.

Если есть root, то враг уже внутри.

Вот как раз топик о том что это не так. Рут тоже ограниченный пользователь, особенно если есть selinux или другая RBAC. Именно поэтому рут не может подгружать модули — потому что у него отнють не все права есть.

Врядли будет подходящий эксплоит, придется самому костылить: готовые сплоиты чаще всего под х86, а у ТС может быть, скажем, какой-нибудь мипс китайский или альфа.

Ну ок. И как мне выполнить код уровня ядра, если у меня есть root но нет возможности сделать insmod, kexec, писать в /dev/mem, /dev/kmem, /proc/kcore ?

Обычно проверятор бутлоадера сидит внутри SoC.

Возможно он и в SoC. Известно только то, что измененный u-boot не работает, а где физически расположен проверяющий его код - хз

А доки на соц луркал? Вдруг там чего интересное есть.

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

а у ТС может быть, скажем, какой-нибудь мипс китайский или альфа.

Более чем уверен :)

Ты хотя бы версию ядра скажи тогда.

Наличествует ли /proc/sysrq-trigger ?

Сейчас нет возможности посмотреть. Но предположим что он есть. Что с ним можно сделать?

Ну допустим linux-3.8.x linux-3.10.x

http://www.cvedetails.com/cve/CVE-2014-9644/
Да и вообще: вот (cvedetails.com). Там фильтр по уровню цве делаешь и ищешь, что интересно.

Сделай бинарный патч для ядра

пост не читай @ сразу отвечай

Запатчить или подменить ядро в /boot/ тоже не вариант.

Сделай бинарный патч для ядра

Запатчить или подменить ядро в /boot/ тоже не вариант.

Замени загрузчик

Уже советовали ;)