> Посмотрел. Ничего похожего, на самозащиту ядра в виде W^X не нашёл (по
> крайней мере в MI- и i386-коде). Правда, чем больше искал, тем Вы лучше спросите. А то все ищут, никто не находит, а вопрос повис.
> больше понимал, что не уверен в том, что ищу то же
> самое, о чём говорите вы. :) Вы имели в виду, что
> если ядро в какую-то страницу памяти что-то пишет, то потом оно
> же эту страницу памяти не будет выполнять? Если говорить о страницах,
Ядро не должно иметь доступ на выполнение страниц, в которые оно имеет доступ на запись. Не только своих, кстати, но и пользовательских. На x86 это достижимо, на amd64 - достижимо с оговорками.
> которые мапятся в юзерленд, то эта проблема уже решена. Если говорить
> о страницах, где выполняться может само ядро, то такая ситуация в
> принципе невозможна (при условии корректной работы подсистемы выделения памяти, разумеется,
Не понял, какую именно ситуацию вы имели ввиду.
> но если в этой подсистеме есть ошибки, то говорить о какой-либо
> защите бессмысленно изначально). Ну или я не вижу за деревом леса...
Ошибки могут быть и есть везде, совершенство недостижимо, но это не повод опускать руки.
> Надо будет ещё раз поглядеть в код опёнковского systrace. Вдруг чего и
> получится починить... GrSecurity хорош, не спорю, но в данном случае, как
> вы понимаете, немного мимо. :)
Кстати, в качестве примера архитектуры он вполне подходит. Systrace - выкидыш, который дискредитирует идею MAC в глазах прагматиков тем, что создаёт огромный оверхед при минимуме сомнительной пользы. MAC, будучи средством борьбы со следствием, должен быть гораздо скромнее в требованиях.
> Гм. Это ж только userland-часть. Так-то systrace(1) и в Опёнке не "сломанный".
> А проблема-то связана с копированием аргументов в ядро и далее...
Там ссылка в README на патч для ядра:
http://www.citi.umich.edu/u/provos/systrace/linux.html
