>[оверквотинг удален]
> то запретить исполнение можно не указывая PROT_EXEC - что и делается
> в malloc функции неяно. Запретить записывать по месту кода - это
> уже делается явно. Получается, что из W^X только одна часть выполняется
> неявно, а другая - как технология здравого смысла. Получается, что если
> в коде не встречается записи W^X, то это не значит, что
> эта технология никак не используется в той или иной ОС. Названия
> порой удобно размещать в тексте учебников и рекламных буклетах. Но даже
> где заявленная технология есть, то это еще не значит, что кто-то
> специально ксорит биты W и X для страниц памяти, поскольку это
> мешает переносимости кода.

Тут и возникает дилемма: позволять использовать потенциально опасный, но как-то пашущий, код, или же принудить заменить его чем-то более безопасным, но не факт, что существующим... Не думаю, что тут есть простое универсальное решение.

>> ...в реальности паразитная нагрузка ниже, так как относится только к контексту выполнения приложения...
> Всецело согласен. Штука включена в последние FreeBSD (не вспомню, с какой версии),
> что действительно не дает использовать некоторые из уязвимостей. В связи с
> его введением перестали работать некоторые старые программы. Но я все равно
> - просто щаслив, шо я теперь в полной безопасности! [BigHo тут
> немного юродствует вслух для поднятия своего настроения]

;)

>> ...securelevel...
> Не понял, в чем разница если значение равно -1 и "А для
> разработки обычных и это не требуется".

В OpenBSD securelevel=1 по дефолту. Соответственно, после установки и настройки на выбор делается "chflags schg /etc/rc.securelevel /etc/rc /sbin/init /bsd /boot /etc/boot.conf" (для параноидальности), либо "echo 'securelevel=-1' >>/etc/rc.securelevel" (для разработки модулей ядра и т.п.). Из обслуживаемых мной сейчас систем первое (вместе с установкой securelevel в 2) проделано, если правильно помню, на двух гейтвеях, а второе вообще нигде, так как заниматься отладкой обычных программ можно даже при securelevel=2.

Хотя вообще, конечно, это не столько превентивная мера, сколько частично помогающая в восстановлении системы.

> Основная мысль, тем не менее, понятна.

Ну и отлично. :)

>> Мир несколько сложнее, чем вы здесь утверждаете.
> "Неуж... Черт! Будь у меня еще немного больше времени, и я бы
> сам мог догадаться! Нельзя же так, да еще без предупреждения разрушать
> последние детские илюзии! Тьфу на вас!" :)

Передавайте привет вашей категоричности. :)

> Ничего не могу сказать про OpenBSD, кроме нескольких интересных для меня вещей,
> например, замена chroot - когда процессы можно строить по ирархической схеме
> относительно привилегий и областей видимости друг-друга - вау! Не помню, где
> смотрел демонстрацию латвийского разработчика.

Если вы про sysjail, то с ним всё несколько грустно, т.к. требуется обойти фундаментальную проблему с systrace(4), связанную с race condition в многопоточных приложениях... :( Так что пока что systrace хорош лишь, скажем, для ловли кривых установочных скриптов в портах (собираю всё с USE_SYSTRACE=Yes, ни разу не пожалел).