На все отвечать не буду, но прочёл всё.> JIT не будет работать с W^X. Почему-то. Data2code transform тоже не будет.
W^X это фундаментальный и принципиальный момент для безопасности архитектуры.
"Все что исполняется никогда не должно изменятся, а что изменяется никогда не должно исполнятся" - это правило основа всей ИТ безопасности.
>> Google Chromium имеет JS движок без JIT,
> А вы им еще и пользоваться пробовали?
На многих архитектурах с W^X люди пользуются.
>> с DAC, которые запретят запустить бинарь собраный/скачаный пользователем.
>> Система разрешает запуск только корректно установленного ПО. Но это уже другая история.
> Это все прекрасно - кроме того что с одной сторонй DAC достаточно хлипкий и уповать только на него да ну нафиг.
Второй фундаментальный принцип ИТ безопасности утверждает, что сначала необходимо настроить DAC. Правельно настроеный DAC даёт вполне безопасную систему.
И только после настройки DAC стоит заморачиватся c MAC и прочим.
Сами технологии виртуализации не разрабатывались как технологии безопасности. Но совмещение PAX+Grsecurity+виртуализация даёт неплохой результат. Особенно интересны новые OS для безопасной виртуализации на SPARK: https://muen.sk/
> На более низком уровне всякие ROP
У меня ROP закрыт: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
> и прочие фокусы с неявным контролем дают много опций как сделать что-то вредное легитимному хозяину системы даже без совсем уж записи и выполнения кода.
это какие?
>[оверквотинг удален]
> концептуальном уровне отличие в том что система может им рулить, а
> юзер напрямую нет. И если его можно на страничном уровне как
> W^X запрограмить - не вижу реальных проблем. В конечном итоге система
> (кернел) свое в такой системе у юзера отспорить чисто технчески может.
> А захочет ли и почему так - это уже административный вопрос
> а не технический. Сама железка может обеспечить эффективный и быстрый энфорс
> W^X на уровне тех же прав памяти.
> ...
> Я вообще не понимаю почему вам мало атрибутов памяти MMU, при обеспечении
> что их только система крутить может. И это вполне быстро.
Хочу увидить реализацию защиты памяти и сравнить её размер и скорость работы с реализацией и работой NX+PAX.
Вот например для ARM с защитой памяти есть большие проблемы и костыли с анклавами, а реальной безопасности нет.
> А конкретно x86-32 был куском дурных проблем.
> ...
> Скорее, половина вон того было актуально для кривого 32-бит уродца с полутора
> регистрами без нормальной относительной реализации - и специфична для именно его
> чудесатых проблем, когда программы вообще не релокатабельны без жутких костылищ.
i686 и сегодняшние x86_64 с софтом собраным c -fPIE -fPIC нормально работают с ASLR и описанных тобою проблем нет: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309
Но, если кто гвоздями в асемблере намертво прибил адреса памяти (для некоторых оптимизаций mmx, sse, ...) то да надо пересобрать прогу и писать позиционно независимый код. Есть вся документация
equery h pic
выдало 1 архиватор и 5 прог связаных с видео. Пришлось их собрать без аппаратного ускорения mmx, sse* на x86_64 чтобы получить позиционно независимый бинарь для запуска в ASLR ядре.
А "Full RELRO" у меня везде без проблем. Это о либах, опции к ld: asneeded, now, relro.
> И тем не менее, половину патчей от оных и GRSec в современные
> ядра НеАнонимы вполне себе портанули. Ту их часть которая не ломает
> по жесткому продакшны народу. У тех господ есть и весьма радикальные
> фичи, много чего в реальном мире ломающие или создающие иные технические
> проблемы.
Читать доки надо перед тем как включать, или пользоватся стандартными профилями: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
> Линукс портабельная система. Вот лично меня линукс интересует на ARM (-el,-hf,aarch64),
> MIPS, RISCV, x86-64. Итого 6 (суб)архитектур. С своими идеями как там
> и что. И я предпочту чтобы секурно было более-менее везде, ага.
Для ARM защиты памяти нет, там костыли, не знаем как писать защиту памяти.
MIPS не имеет NX, но как PPC* имеет другое и мне не известно смог ли кто написать для него W^X ядро ОS.
x86-64 есть инструкции NX и есть эталонные реализации OS с защитой памяти: Linux+PAX, NetBSD.
RISC-V под вопросом вообще сама возможность написания OS с защитой памяти.
Тестируй: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309