Gentoo Hardened vs egyéb disztribúciók

Mindez a forrásban van! A Gentoo edzett egy biztonság által vezérelt terjesztés nagyon sokat csomagol annak érdekében, hogy valóban biztonságos legyen.

De megéri-e a fordítást? Nagy kérdés a linuxos fórumok között.

Nézzük meg a Gentoo edzett profilját a biztonság szempontjából:

miközben hozzáad némi secu-t olyan kevés, hogy a legtöbb esetben nem éri meg. Nagyobb biztonságot nyújt egy bináris disztribúción, mert mindenkinek ugyanazok a bináris fájljai vannak, és a támadónak nem kell kitalálnia, hová tölthet be egy adott kóddarabot, de egy forrás-disztribúció futtatásával a címtere már nagyon egyedi. Az egyetlen eset, amikor Bizonyos biztonságot nyújt, amikor a támadó megpróbálja kitalálni egy címet egy kizsákmányoláshoz, így a rossz kitalálás valószínűleg összeomolja a folyamatot, és újratöltésre kerül egy új címre. Van-e elég értékes adata ahhoz, hogy a támadó át tudjon menni ezen gond, ha megszerzi? Ha igen, akkor keményített profilt kell használnia, de a fizikai biztonság és a lemez titkosítása fontosabb, mert ha ennyit ér, akkor könnyebb csak kirabolni.

Ne feledje, hogy nincs edzett asztali profil, így önmagában ez némileg megnehezíti, ha azt a számítógépen tervezi használni.

Egy másik ok az, ha valami olyasmit szeretnél használni, mint a SELinux (amihez nincs szükség edzett profilra), amely nagyon finom szemléletet biztosít a hozzáférés-vezérléssel kapcsolatban, ugyanakkor nagyon korlátozó is. Úgy gondolom, hogy csak a nagy hálózatoknál érdemes megtenni, sok felhasználóval és az érzékeny adatokhoz különböző szintű hozzáféréssel.

Szükségem volt néhány SELinux-szolgáltatásra, de az AppArmor szokatlan módon történő használatára számítottam, hogy megvalósíthassam őket, mert a SELinux túl sok baj. Az AppArmor csak annyit tesz, hogy biztosítja a folyamatok elkülönítését vagy a sandbox-ot. Ha a támadó explointon keresztül jut hozzáféréshez, akkor csak azokhoz a fájlokhoz férhet hozzá, amelyekhez a kihasznált szolgáltatás hozzáfér. Ezt az összes olyan profillal használom, amely megakadályozza az összes világon írható és otthoni könyvtár végrehajtását, valamint az ssh / pgp kulcsokhoz, kulcstartókhoz stb. való hozzáférést. Ez szervereknél és asztali gépeknél jól működik, és nem túl korlátozó. És ha fejlesztés céljából az otthoni könyvtárból kell végrehajtanom a kódot, akkor indítson el egy korlátlan héjat sudo-n keresztül. A laptopomat nyitva hagyhatom nyitva a pénztárcával (a kwallet pam modult használom), és nagyon nehéz lesz bármit beszereznie, például ssh kulcsokat vagy jelszavakat (nekem is vannak javításaim a kwallet számára, így jelszót igényel ord a mentett jelszavak megjelenítésére), de a szükséges programoknak hozzáférésük van hozzájuk.

De mitől edzett? néhány elemet is megnézhetünk:

• A PaX egy kernelparancs, amely megvéd minket a verem és a halom túlcsordulásától. A PaX ezt az ASLR (címtérelrendezés véletlenszerűsítése) segítségével végzi, amely véletlenszerű memóriahelyeket használ a memóriában. Minden héjkódnak egy címet kell használnia a beágyazáshoz a kód végrehajtásának elérése érdekében, és mivel a memóriában lévő puffer címe véletlenszerű, ezt sokkal nehezebb elérni. A PaX további védelmi réteget ad azzal, hogy a program által használt adatokat egy nem futtatható memóriaterületen tartja, ami azt jelenti, hogy a támadó nem tudja végrehajtani azt a kódot, amelyet sikerült a memóriába írni. A PaX használatához PaX-kompatibilis kernelt kell használnunk, például keményített forrásokat.
• PIE / PIC (pozíciótól független kód): Általában egy futtatható fájlnak fix alapcíme van, ahol vannak betöltve. Ez az a cím is hozzáadódik az RVA-khoz, hogy kiszámolhassák a futtatható fájlban lévő függvények címét. Ha a futtatható fájl PIE támogatással van lefordítva, akkor bárhová betölthető a memóriába, míg fix címen kell feltölteni, ha PIE támogatás nélkül fordítják le. A PIE-t engedélyezni kell, ha a PaX-t akarjuk használni az ASLR előnyeinek kihasználásához.
• RELRO (relocation read-only): Amikor a futtatható fájlt futtatjuk, a betöltött programnak írnia kell néhány szakaszba, amelyek nem Az alkalmazás elindítása után nem kell írhatóként megjelölni. Ilyen szakaszok: .ctors, .dtors, .jcr, .dinamikus és .got [4].Ha ezeket a szakaszokat csak olvashatóként jelöljük meg, akkor a támadó nem fog tudni használni bizonyos támadásokat, amelyeket a kódfuttatás megszerzéséhez használhat, például a GOT-tábla bejegyzéseinek felülírása.
• SSP ( stack-smashing protector) felhasználói módban használják; védi a verem túlcsordulásait azáltal, hogy egy kanárit helyez a veremre. Amikor a támadó túlcsordítani akarja a visszatérő EIP-címet a veremben, akkor a véletlenszerűen kiválasztott kanári csatornát is túl kell töltenie. Amikor ez megtörténik, a rendszer észlelheti, hogy a kanári felül lett írva, ebben az esetben az alkalmazás megszűnik, ezáltal nem engedve a támadónak tetszőleges helyre ugrani a memóriában, és onnan végrehajtani a kódot.
• RBAC (szerepalapú hozzáférés-vezérlés): Vegye figyelembe, hogy az RBAC nem ugyanaz, mint az RSBAC, amelyet később bemutatunk. Az RBAC egy hozzáférés-vezérlés, amelyet a SELinux, a Grsecurity stb. Használhat. Alapértelmezés szerint a fájl készítője teljes mértékben ellenőrzi a fájlt, míg az RBAC arra kényszeríti a gyökér felhasználót, hogy a fájl felett legyen, függetlenül attól, hogy ki hozta létre. azt. Ezért a rendszer összes felhasználójának be kell tartania a rendszer rendszergazdája által meghatározott RBAC szabályokat.

Ezenkívül használhatjuk a következő beléptető rendszereket is, amelyek a folyamatok és a tárgyakat. Normális esetben az alábbiakban vázolt rendszerek egyikét kell választanunk, mert egyszerre csak az egyik beléptető rendszer használható. A beléptető rendszerek a következőket tartalmazzák:

• SELinux (biztonsággal továbbfejlesztett Linux)
• AppArmor (alkalmazáspáncél)
• Grsecurity, amely különféle javításokat tartalmaz, amelyek a rendszermagra alkalmazható az egész rendszer biztonságának növelése érdekében. Ha engedélyezni szeretnénk a Grsecurity-t a kernelben, akkor egy Grsecurity-kompatibilis kernelt kell használnunk, amely keményített forrás.
• RSBAC (szabálykészlet-alapú hozzáférés-vezérlés): Az rsbac-sources kernelt kell használnunk. kernelt építeni rsbac támogatással.

Mindez a nagy kérdésre vezethető vissza, amint azt korábban elmondtuk? Érdemes lefordítani? Tényleg lejön, hogy hogyan vagy mit biztosít, és megéri-e az erőfeszítést? Vagy képes lesz valóban biztosítani azt, amit nem akar, hogy a kíváncsi szemek láthassák?

Hozzászólások

• Oké, köszönöm mindenkinek a pontosítását ezeket a biztonsági végrehajtási technológiákat. Tehát, ha megértem a véleményét, ezek az elemek nagyon hasznosak a rendszer biztonságának javításához; de megkérdezed ", megéri-e a fordítást? ". Szóval, miért nem engedélyezik őket alapértelmezés szerint néhány nagyobb disztribúcióban? Olvastam, hogy az Asztalon lévő PaX megsérthet néhány bináris fájlt (java vagy Firefox hallatán); ez az egyetlen oka?
• Az oka annak, hogy a PaX és a grsecurity nem az alapértelmezett sok disztribúciónál, a politika és az ego miatt van. Mindkettő fejlesztői olyan személyiségűek, akik erősen ütköznek a Linux kernel dev csapatával. Ezen túlmenően nem kívánnak időt szakítani arra, hogy a javításukat darabokra bontsák, amelyeket az upstream forgalomba hoznak, és ehelyett több idejüket további biztonsági funkciók fejlesztésére fordítják.
• Vegye figyelembe azt is, hogy a grsecurity nem beléptető rendszer. A Spender (a grsecurity készítője) nagyon ingerültté válik, amikor az emberek beléptető rendszernek hívják, majd összehasonlítják a SELinux-szal. : P A Grsecurity a kernelparancsok kombinációja, amely növeli a kernel biztonságát azáltal, hogy kiküszöböli a hibajavításokat. A rendelkezésére álló RBAC beléptető rendszer nem releváns a többihez képest. A Grsecurity ' biztonsági szolgáltatásai olyan kiterjedtek, hogy sokkal több helyet foglalnak el, mint amennyit egyetlen bejegyzésben el lehetne helyezni. Látogasson el a grsecurity.net oldalra, és nézzen meg egy elég átfogó listát.
• miközben ad némi biztonságot, ' annyira kevéssé, hogy ' a legtöbb esetben nem éri meg – Uh, ez teljesen helytelen. A biztonságnak pedig valójában semmi köze a címek elrejtéséhez. ' m csodálkozom , hogy ezt a választ felértékelték.