A számítógépes biztonság terén a PaX (nevezetesen "Pax") a Linux kernel javítása, amely lehetővé teszi az alkalmazások minimális hozzáférési jogainak konfigurálását a memórialapokhoz. Ez egy olyan finom beállítást biztosít, amely lehetővé teszi a programok számára, hogy csak azokat a műveleteket hajtsák végre, amelyek az általuk biztosított funkciók alapján szükségesek, de nem többet. A PaX először 2000-ben jelent meg. 2014 óta csak a grsecurity projekt [1] részeként terjesztik , amely 2017 áprilisa óta vált fizetőssé [2] .
A PaX a memóriában lévő programok adatszegmensét végrehajthatatlannak jelöli (mert definíció szerint nem tartalmazhat végrehajtandó programdirektívákat), a kódszegmenst pedig nem írhatónak, és ezen kívül tetszőlegesből memóriát foglal le a programnak. helyek minden kérésnél (memóriaoldalak véletlenszerűsítése). Minden olyan program, amely megpróbálja átvinni a vezérlést a nem végrehajtható memóriában lévő kódra, kénytelen leállni [1] .
Ez a technika hatékony a különféle kihasználások , például a memóriapuffer-túlcsorduláson alapuló biztonsági rés használatával szemben. Az ilyen védelem kezdetben teljesen megakadályozza a kód közvetlen végrehajtását a memóriából, ugyanakkor alkalmazási szempontból megnehezíti az úgynevezett return-to-libc (ret2libc) támadások végrehajtását (véletlenebbé válnak, kiszámítható eredmény). Ugyanakkor a PaX nem akadályozza meg azokat a hibákat, amelyek a változók és mutatóértékek újradefiniálásához vezetnek.
A PaX-et az azonos nevű fejlesztőcsapat írta. A PaX alapítója jelenleg a nyilvánosság számára ismeretlen okokból inkább névtelen marad.
A számítógépes rendszerek összes sérülékenységének nagy részét a programok hibái okozzák, amelyek lehetővé teszik funkcióik újradefiniálását menet közbeni átírással (közvetlenül a RAM-ban). Számos féreg, vírus működési elve, valamint a rendszerek közvetlen feltörésének számos módszere a memória tartalmának megváltoztatásán alapul rosszindulatú kód beillesztésével, majd végrehajtásával, valamint a memóriaterület tartalmának egy részének szándékos megváltoztatásával történő végrehajtásán. mutatók stb. Ha az ilyen műveleteket bármilyen módon blokkolják, akkor a teljes kár egészen jelentéktelenné válik, vagy lehet, hogy egyáltalán nem, még akkor is, ha a vírus behatolt a rendszerbe. Ráadásul sok féreg (mint például a Sasser ) ebben az esetben egyáltalán nem tud behatolni a rendszerbe.
A PaX az ilyen támadások megelőzésére és a lehető legáltalánosabb megvalósításra jött létre, vagyis a memóriaelérés (olvasás, írás, végrehajtás és ezek lehetséges kombinációinak) vezérlésével megakadályozza az illegitim kódok végrehajtását. anélkül, hogy közvetlenül megérintené magát a végrehajtható kódot. Ilyen alacsony költség mellett a PaX ellenállóbbá teszi a rendszert a feltörésekkel szemben, csökkenti az alkalmazás szolgáltatásmegtagadáshoz ( DoS ) vezető kizsákmányolások számát, vagy távolról figyeli a kódvégrehajtás folyamatát; olyan kihasználások, amelyek az ilyen biztonsági rések segítségével root hozzáférést biztosítanak a támadónak, hozzáférnek egy rendszeren lévő érzékeny információkhoz, vagy más módon kárt okoznak. Ehelyett az ügy bármely folyamat vagy program működésének leállítására korlátozódhat, minimális következményekkel az egész rendszerre nézve.
A DoS támadás által okozott kár leggyakrabban idő- és erőforrásveszteség a megtámadott objektum működésének meghibásodása miatt. Ebben az esetben azonban a PaX megakadályozza az érzékeny rendszeradatok támadás miatti jogosulatlan elérését és terjesztését, magát a támadást pedig nem akadályozza meg. Mindeközben a DoS közvetlen következményei is nagyon nem kívánatosak, különösen olyan rendszerek esetében, ahol a szolgáltatás bármely megszakítása kritikus, és a behatoló behatolása nyilvánvalóan kevesebb kárt okoz, mint a szolgáltatások megszűnése. Ebben az esetben a PaX nem lesz a legjobb megoldás, de ennek ellenére egy meglehetősen elfogadható módszer a fontos információk védelmére.
Sok (de biztosan nem mindegyik) fejlesztő hibája miatt programjaik rosszul kezelik a memóriát. Ez azt a hipotetikus lehetőséget kínálja, hogy egy programot olyasmire kényszerítsünk, amit nem kellene (például kiadni egy privilegizált shellt). A PaX célja nem az ilyen sérülékenységek felkutatása és kijavítása, hanem annak megakadályozása, hogy azokat támadó alkalmazások kihasználják. A hibák következményei minimálisra csökkennek - a program végrehajtása egyszerűen megszakad, ami a PaX szempontjából jobb, mint a veszélyeztetett funkcionalitása.
Meg kell érteni, hogy a PaX nem akadályozza meg közvetlenül a puffertúlcsordulást, hanem csak hatékonyan próbálja elnyomni a vele kapcsolatos lehetséges fejlesztői hibákat, amelyek például a rendszerhez való nem kívánt hozzáférés biztosításához vezethetnek. Vannak azonban olyan fejlesztések, mint például a Stack-Smashing Protector és a StackGuard , amelyek megpróbálják pontosan észlelni magát a puffertúlcsordulást, és leállítják a rendszert kompromittáló programok végrehajtását. Ezt a technikát stack-smashing védelemnek nevezik . A közvetlen támadások közvetlen blokkolására összpontosít, ha lehetséges. Noha a PaX és a stack-smashing védelem lényegében ugyanazt a célt szolgálja, nem cserélhetők fel. Mindkét technológia bevezetése azonban minden bizonnyal biztonságosabbá teszi a rendszert. Egyes Linux-disztribúciók már egyszerre tartalmazzák mindkét összetevőt (PaX és Stack Smash Protection) [3] .
2006 októberéig a PaX még nem került be a kernel fővonalába , mivel a javítás fejlesztői úgy vélik, hogy még mindig nem elég kiforrott. De annak ellenére, hogy a PaX-et számos architektúrán sikeresen használták, még mindig csak részben, vagy egyáltalán nem támogatott számos más architektúrán. Így a PaX sikeresen használatos IA-32 ( x86 ), AMD64 , IA-64 , Alpha , PA-RISC , 32 és 64 bites MIPS , PowerPC és SPARC rendszereken .