>А как на счет grsecurity pax?

Не планируется. При наличии времени (и, возможно, спонсора), есть потенциальный план делать свои hardening изменения и дополнения на основе ядер OpenVZ - как в код mainstream ядер, так и в код специфичный для OpenVZ. Например, возможность запретить отдельному контейнеру выполнять 32-битные или 64-битные системные вызовы, тем самым сокращая риск атак на ядро. Это лишь один пример, у меня есть список желаемых доработок такого рода. Вероятно, многое из этого сможет войти в upstream.

PaX - хорошая штука, и автор реально хороший специалист. Но есть причины PaX в Owl не интегрировать. Насколько я знаю, PaX не разрабатывается и не поддерживается для RHEL'овых ядер - т.е. портирование и поддержка были бы на нас (а это время и риск привнести баг или даже уязвимость - а PaX реально сложная штука, которую кроме его автора никто "до конца" не понимает - я слегка читал код, там есть очень много важных, но не комментированных деталей реализации, которые без знания "внешних обстоятельств", только из кода самого PaX, с уверенностью не понять - можно только предполагать что это так-то, вероятно, потому-то), либо же нам надо было бы на каких-то условиях договариваться с его автором.

PaX несет две основные функции - (1) предотвращение использования некоторых классов уязвимостей в user-space программах и (2) то же самое для в чем-то схожих классов уязвимостей в ядре. Что касается #1, то в RHEL-ядрах есть exec-shield. Он "слабее", но намного проще (меньше кода, нет замедления), и он уже есть. На процессорах с битом NX при сборке ядра с PAE, а также при 64-битном ядре, его эффективность схожа с PaX. (Правда, в моем списке есть и небольшая доработка exec-shield тоже.) Что касается #2, то пока мы ограничились vm.mmap_min_addr, что опять же "слабее", но гораздо "дешевле" PaX'а. (Кстати, эффект подобный PaX'овому UDEREF, с точки зрения безопасности, достигается "enterprise" сборкой RHEL-ядра с 4G/4G address space split, без всяких дополнительных патчей, но это слишком "дорого" с точки зрения производительности, поэтому это я отношу скорее к юмору. А еще можно просто использовать ядро Linux 2.0, с тем же эффектом (да, там было лучше), но это тоже юмор.)

Про остальной grsecurity пока не пишу, предполагаю что этого в вопросе не было, да и время жалко, а короткие, но верные и полезные ответы у меня не получаются. ;-)