Valamit valamiért!
Így van. a PaX készülő megoldása azért lesz jobb, mint az ilyen futásidejű buffer overflow ellenőrzések, mert nem magának a túlcsordulásnak a _tényét_ próbálja ellenőrízni és ellene védekezni - ami lassú és nehéz -, hanem annak _kihasználása_ ellen nyújt védelmet, így csak néhány plusz utasításra van szükség végrehajtásáramlás-változás (sic! :) előtt. Emiatt nem lesz annyira lassú és majd a kernel is védhetővé válik vele anélkül, hogy több száz százalékos overhead keletkezzen.
Még annyit hozzátennék, hogy a felhasználóknak shell hozzáférést nem adok (ha mégis, csak rbash-t egyetlen könyvtárral a path-ban)
Az (r)bash is tartalmaz biztonsági hibákat, ráadásul ezeket már lokálisan lehet kihasználni így, amely ellen az ASLR pláne nem véd semmit (tele van infoleakkel a userland, lásd /proc/{pid}/maps és hasonlók).
MINDEN könyvtárat, amit a felhasználók is írhatnak noexev,nodev opcióval mountolt fájlrendszeren tartok
PaX nélkül a noexec mount kijátszható. {Shell,Perl,Python,Ruby,etc.} szkriptek futtatásához pedig egyébként sincs szükség exec mountolt filerendszerre.
Ilyen körülmények között is vállalhatatlannak tartod a fentebb kirakott paxtest eredményeket
Én igen, de ettől neked még megfelelő lehet. :)