> Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например.А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще само ядро, для которого тоже W^X применяется?
Смотри на ситуацию вирусной атаки - все процессы в памяти имеют уязвимость переполнения буфера и при вирусной атаке ядпо с W^X их всех прибет.
W^X очень простая, дешовая и эффективная техника безопасности. Она идеальна для рабочей станции секретарши, смартфона, планшета, ноута итп.
В системах для которых кретически важна безперебойная работа используют другие, более дорогие, техники безопасности. А PAX включают только в режиме softmode для журналирования.
> Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда?
Тогда виноват не админ с PaX а программист...
> mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы.
Это делать можно, например clamav так и делал. Но это неправильно. Лучше програмистам давать возможность сборщикам пакетов выбор JIT ветки кода в момент конфигурации перед компиляцией.
> Если конструкция в целом умеет переживать смерть отдельного процесса без остановки сервиса, то не вижу проблем даже и в прибивании за нарушение гарантий памяти. Если не умеет, то мы нарвёмся на проблемы и без проблем с безопасностью.
> Требование-то, на самом деле, к непрерывности предоставления сервиса, а не к модели памяти. От этого, имхо, и нужно рассуждать.
Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера.
Общее правило: проактивные системы защиты, которые убивают процессы, нельзя использовать в системах критических для жизни людей, экологии, производства ИТП...
